Every Vadyl capability can become your project capability.
Vadyl uses entities, commands, workflows, agents, analytics, events, runtime handlers, MCP tools, auth, observability, and governance for its own platform behavior. Project-scope parity means a Vadyl project can use those same shapes for itself: author them, publish them, install them from other projects, expose them through SDK/CLI/API/MCP/dashboard, govern them, bill them, observe them, and explain them through the Plane Capability Graph.
Same plane. Project authority.
A project-scoped capability is not a weaker plugin. It is the same UCSA contract with project identity, ancestry, branch, governance, publication, installation, grants, consumption evidence, billing, and observability attached.
Author
Define entities, workflows, commands, agent skills, dashboards, analytics, events, auth schemes, handlers, and policies as typed project state.
Project
ContractProjection turns that state into REST, OpenAPI, GraphQL, gRPC, SDK namespaces, CLI groups, MCP tools, dashboard actions, webhooks, and realtime channels.
Publish
ProjectCapabilitySurfaceManifest selects typed slices and signs a versioned surface for other projects to install.
Install
Consumer projects pin a version, narrow grants, set billing attribution, and receive a branchable SurfaceInstallation record.
Consume
Invocations emit ProjectCapabilityConsumptionDescriptor records so usage, billing, lineage, dependency impact, and explainers see the same truth.
Reason
The PCG models provider project, consumer project, installation, exposed operation, command, workflow, agent skill, measure, trigger, and effect as typed nodes and edges.
The project capability matrix
The examples below are deliberately broad. Entities are only the first example of the rule; the same model extends across every safe plane.
| Vadyl capability | Project-scoped form | Projected through |
|---|---|---|
| Entities | Project-owned nouns, relations, transitions, access, triggers | REST, GraphQL, gRPC, SDK, CLI, MCP, dashboard |
| CLI | Project commands and operational command groups | vadyl surface command, generated shell completion, CI output |
| Workflows | Durable starts, signals, compensation, approval tasks | SDK, CLI, REST, MCP tools, automation actions |
| Agents | Skills, tools, memory scopes, model bindings, run policies | MCP tools, dashboard actions, SDK agents namespace |
| Analytics | Measures, metrics, dashboards, materializations, reports | SDK analytics, dashboards, CLI measure, PCG nodes |
| Events | Event vocabulary, triggers, realtime topics, webhook topics | Realtime, webhooks, automation triggers, MCP resources |
| Runtime | Handlers, jobs, edge units, scaling and ingress policy | Runtime Fabric, CLI runtime-fabric, explainability |
| Governance | Auth schemes, quotas, billing meters, install grants | ProjectCapabilityGrant, exposure binding, usage ledger |
A published capability appears everywhere developers work.
A project-published surface is not just a marketplace listing. It becomes protocol, SDK, CLI, MCP, dashboard, automation, and observability surface from the same exposure binding.
Project CLI commands
A provider can publish command groups such as fraud.review, ledger.reconcile, support.escalate, or billing.invoice. Consumers install them as governed commands.
Typed SDK clients
Installed surfaces project into typed namespaces with version pins, grant-aware methods, canonical errors, retries, and descriptor hashes.
MCP tools and resources
Agent-capable clients see only installed tools, prompts, and resources allowed by ProjectCapabilityGrant and exposure policy.
Automation actions
Installed workflows, event triggers, scheduled handlers, and agent skills appear as PCG actions and triggers for declarative automation.
Usage and billing
Every call carries installation id, provider project, consumer project, billing scope, correlation id, reason block, and quota dimension.
Branchable lifecycle
Publish, install, upgrade, suspend, deprecate, revoke, and uninstall are branchable and reviewable before promotion.
Not just entity slices
UCSA plus project authority
PCG sees authoring, install, consume
API, SDK, CLI, MCP, dashboard
Build a product that can become a platform.
Start with your own project. Publish the parts other teams should depend on. Install the parts another project already owns. Keep every boundary typed, governed, observable, billable, and explainable.