Core Concepts

Project-scope parity

The rule that makes Vadyl fractal: every safe platform plane can also be authored, published, installed, governed, observed, and exposed by projects.

Project-scope parity means the capabilities Vadyl uses to run itself are available to Vadyl projects through the same architecture. A project can define entities, operations, workflows, events, realtime channels, webhook receivers, CLI commands, dashboard actions, agent skills, analytics measures, auth schemes, scheduled handlers, runtime policies, storage/cache/distribution behavior, and other safe surface slices as project-owned capability.

This is why entities feel native on Vadyl: they are not special-case code generation. They are the first visible example of a wider rule. The same projection, grant, graph, publication, installation, and observability model applies to every plane that can be safely scoped to a project.

The law

If Vadyl can use a module as a platform capability, a project can use the same capability shape when project authority, safety, governance, and isolation rules allow it. The project-scoped form is the same contract with project identity, ancestry, branch, publication, installation, grant set, billing attribution, observability, and explainability attached.

What projects can publish

PlaneProject-published slice
DataEntities, relations, operations, access rules, triggers, association templates.
ProjectionREST operations, SDK namespaces, CLI command groups, MCP tools, dashboard actions.
ExecutionHandlers, workflows, scheduled jobs, event consumers, webhook receivers, management actions.
AIAgent skills, prompts, tools, memory scopes, automation actions, model routing policies.
EventsEvent vocabulary, realtime channels, webhook topics, subscription filters.
AnalyticsMeasures, metrics, perspectives, reports, dashboards, materializations.
GovernanceAuth schemes, quota dimensions, billing meters, install grants, exposure policies.
Substrate policyStorage namespaces, cache policies, distribution publications, runtime topology intent.

How UCSA and PCG split the work

The Unified Capability Surface Architecture defines the closed taxonomy, descriptors, bindings, projection shapes, implementation sources, and grant envelopes. Projects author instances inside that taxonomy; they do not invent arbitrary new platform kinds.

The Plane Capability Graph then records the resulting capabilities as typed nodes and edges: provider project, consumer project, installed surface, exposed command, workflow, event, measure, tool, trigger, effect, policy, dependency, and consumption record.

Publish, install, consume

A provider project publishes a ProjectCapabilitySurfaceManifest. That manifest selects typed slices from the project: entities, operations, commands, workflows, agent skills, measures, dashboards, events, webhooks, auth schemes, runtime handlers, storage policies, and other declared facets. Each slice produces exposure bindings and PCG nodes.

A consumer project installs a version through an InstallationManifest. Installation pins the provider version, narrows the allowed grants, declares billing attribution, resolves exposure bindings, and adds installed resources to the consumer's runtime descriptor.

When the consumer invokes the installed surface, Vadyl emits a ProjectCapabilityConsumptionDescriptor. That record is the shared evidence for usage billing, quotas, explainability, dependency impact, audit, and graph traversal.

CLI is included

CLI is a first-class projection. A project can publish a command surface just as it can publish operations or events. The installed command remains governed by exposure bindings, project grants, output contracts, exit-code mapping, audit, and usage records. It is not a shell escape and it is not a second authority beside the API.

Where to go next