Can this be done?
Veil receives the plan, resolves the requested capabilities, and makes unavailable operations explicit.
A capability-driven execution runtime
Reasoning proposes.
Veil governs execution.
Veil sits between reasoning and infrastructure. Your software, planners, or human workflows produce an ExecutionPlan. Veil validates the plan, authorizes each operation, and executes registered capabilities.
Reasoning / software / humans → ExecutionPlan → Veil → capabilities / providers
Execution boundary
PLAN READY
EXECUTION 0142
Summarize the local document.
Proposed ExecutionPlan
Approval required
An external write is waiting for approval.
The missing layer
Reasoning is not execution.
Reading files. Calling APIs. Using browsers. Running commands. Applying execution controls. Recording outcomes. Every system that moves from deciding to doing eventually has to solve the same engineering problem.
May it proceed?
The configured authorizer allows or denies each operation using resolved input and caller context. Human review, when needed, belongs to the application.
Make it real.
Resolved capabilities perform the work once execution requirements are satisfied, while Veil records the lifecycle and result.
Public package
Veil Core is available today.
Install @veil-runtime/core on Node.js 24 or newer to define
capabilities and execute explicit plans. The latest published version
is v0.1.3. These docs target the v0.2.0 release candidate.
$
npm install @veil-runtime/core
The published package includes contextual execution authorization and the
public inbound MCP adapter while preserving the same governed
ExecutionPlan → OperatorRuntime → Capability path.
Everything around it can change
The reasoning system can change. The infrastructure can change. The capabilities can grow. The execution model stays the same.
Architecture
Proposal and execution remain separate.
Software, humans, and planners decide what should happen. Veil validates their declarative plan and capability contracts, resolves prior results, authorizes each step, and records outcomes. Capabilities use providers to interact with infrastructure.
Reasoning / software / humans
→
→
Execution boundary
Governed execution · capability resolution · lifecycle events
→
→
→
ExecutionPlan
A structured proposal describing the operations that should be executed. The plan expresses intent in executable form, but does not itself perform the work.
Steps run sequentially. Earlier results can feed later inputs through result references. Jobs retain outcomes and lifecycle events. Deterministic lookup and ordering do not imply deterministic capability or provider results.
Capabilities
Define what exists.
A capability is an operation explicitly made available for
execution. Register capabilities once, then reuse the same
execution machinery across AI, applications, automations,
and human-driven workflows. The examples below describe capability
shapes you can define; they are not bundled integrations in
@veil-runtime/core.
Files
filesystem.file.read
APIs
http.request
Browsers
browser.operation
Databases
database.query
Commands
shell.execution
Your systems
capability.custom
Extend Veil
Make anything a capability.
Veil does not need to understand every system you use. Expose the operations you want to make executable, register them, then submit plans through validation and authorization.
01
YOUR SYSTEM
Existing operation
restartService()
→
02
VEIL
Capability
service.restart
→
03
REGISTER
Available to plans
runtime.use(module)
→
04
EXECUTE
OperatorRuntime
Job
Your infrastructure stays yours
Wrap the operation.
Veil handles the execution boundary.
A capability can sit in front of a function, API, database, shell command, browser operation, SDK, internal service, or MCP tool.
You do not move your infrastructure into Veil. You decide which operations become available for controlled execution.
import { createCapability } from "@veil-runtime/core";
const restart = createCapability<{ service: string }, void>({
name: "service.restart",
version: "1.0.0",
description: "Restart an application service",
risk: "write",
inputSchema: {
service: { type: "string", required: true,
description: "Service name" }
},
async execute({ input }) {
await infrastructure.restart(input.service);
}
});
infrastructure is your application’s provider. Register the
capability through runtime.use(module), as shown below.
Writes require an application-configured
authorizer;
the default policy denies them. The quickstart uses the public API shared by v0.1.3 and the v0.2.0 candidate.
Developer path
From your code to controlled execution.
Veil is deliberately small at the integration boundary.
Define what may be executed, register it, provide an
ExecutionPlan, and let the runtime handle execution.
Define a capability
TypeScript
What happened?
Expose one controlled operation.
Your application still owns the implementation. Veil only needs a capability contract around the operation you want to make available for execution.
Veil Starter
Run the demo. Learn the boundary. Replace it with your own.
Clone the repository and run the interactive Starter locally. Experience mode shows the outcome; Learn mode reveals the real plan, job, events, authorization decisions, and MCP translation.
Clone and build
git clone https://github.com/veil-runtime/veil.git
cd veil
npm install
npm run build
Run the Starter
Install dependencies in
examples/veil-starter.
Start the trusted application server.
Start the browser client in a second terminal.
Open the local Vite URL.
Learn and extend
Lessons 01–07 explain capabilities, plans, governance, and MCP.
Lesson 08 turns the demonstration into an application starting point.
Replace a demo capability with one useful operation from your system.
Keep execution on the same governed runtime path.
Bring your own intelligence
AI is optional.
Veil executes plans. It does not require a particular model, provider, or even an AI planner. Anything capable of producing an ExecutionPlan can use the same execution runtime.
HOSTED AI
Your hosted model
↓ Planner ↓ ExecutionPlan
LOCAL AI
Your local model
↓ Planner ↓ ExecutionPlan
NO AI
Your application
↓ ExecutionPlan
EXTERNAL SYSTEM
Automation / human / service
↓ ExecutionPlan
All roads lead to the same boundary
ExecutionPlan → OperatorRuntime → Capability
Bring your own models. Bring your own infrastructure. Build your own capabilities. Meet at one governed boundary.
Interoperability
MCP connects tools. Veil keeps one execution model.
MCP is an interoperability layer around Veil, not a second
execution path. Adapters can translate MCP invocations into
ExecutionPlan instances, and MCP-backed capabilities
can sit behind the same runtime boundary. Veil Core v0.2.0 publicly
exports the inbound McpAdapter, which requires an
OperatorRuntime and creates no alternate execution path.
What is public today
A usable core, an early ecosystem.
@veil-runtime/core v0.2.0 provides the public execution
boundary, contextual authorization, and inbound MCP adapter.
Providers and integrations can be composed around that boundary
without changing the execution model.
Public runtime API
OperatorRuntime
OperatorRuntimeOptions and ExecutionAuthorizer
ExecutionPlan and execution-step types
Job, result, and event types, including capability.denied
Capability and capability-module contracts
Capability SDK
Declarative capability authoring
Capability modules
Middleware support
Lifecycle and timeout middleware
Planning flexibility
Bring your own planners
Deterministic or non-AI planning
Explicit ExecutionPlan boundary
No required AI vendor
Extensible boundaries
Custom capabilities
Custom providers and integrations
Infrastructure remains under application control
Public inbound McpAdapter at the interoperability boundary
v0.2.0 · release candidate
Know what is registered. Govern what runs.
Deterministic capability introspection describes the registered execution
surface. listCapabilities() returns inventory;
describeCapability(name, version?) performs exact lookup.
The new CapabilityDescriptor contains detached, mutable metadata.
This contract is included in the v0.2.0 candidate; see local candidate installation.
What is registered?
Names, versions, descriptions, risk and declared input fields. Inventory follows registration order; lookup matches names and versions exactly.
What is relevant?
Your reasoning or application logic selects the capability. Veil adds no semantic search, ranking, embeddings or LLM-driven selection.
May this caller execute it?
Introspection grants no permission and does not establish provider readiness. Submit an ExecutionPlan through the normal governed execution path.
v0.2.0 also contains event-subscriber failures, rejects malformed authorization, requires own properties in result paths and unique step IDs per plan, and captures plan structure before admission. Nested input values remain shared: authorization-to-invocation deep value stability is not guaranteed. Read the scope and limits.
Where Veil is going
Architecture first. Ecosystem next.
The v0.2.0 candidate includes governed-execution hardening, deterministic capability introspection, and the developer documentation refresh. See the v0.2.0 scope and limits.
PUBLISHED
Public Core v0.1.3
CANDIDATE
v0.2.0 · hardening + introspection
IN v0.2.0
Developer documentation refresh
AFTER
Real-world ecosystem
Open source · Apache-2.0
Build the execution layer once.
Use it from AI, applications, humans, and automation without coupling intelligence directly to execution infrastructure.