capability record
requiredversioned, declared, verified
Each reusable engine part should declare input material, output lanes, owner, auth boundary, example command, known failure modes, and last verified state.
The engine layer
Capabilities are the reusable parts an agent composes before it can touch frontier state: procedures, source connectors, checks, harnesses, compute systems, and subject systems. They produce attempt packets, reviewable changes, traces, checks, and source material. They do not become authority until review accepts a frontier event.
capability records
0 proceduresProcedures an agent or human can invoke: source harvest, verification, curation, prediction, repair, and finding review work.
view capabilities →
capability records
0 recordsVerifiers, resolvers, CLIs, and harnesses with explicit input material, output lanes, auth boundaries, and release checks.
view capabilities →
capability records
0 systemsCompute engines agents run on, plus subject systems whose internals can become reviewed frontier findings.
view capabilities →
engine index
derivedRoute slugs, content-addressed vfr ids, data-source mode, and hub/local resolution boundaries. It is a resolver, not the record.
inspect index →
authority boundary
not automaticCapability outputs, index rows, system runs, and source connectors become useful source material before accepted review events make them frontier state.
inspect trust →
capability record
requiredEach reusable engine part should declare input material, output lanes, owner, auth boundary, example command, known failure modes, and last verified state.
The engine layer stays useful because every reusable part has the same boundary: declared scope, bounded execution, review output, and provenance-derived credit.
contract
A capability names the objects it can read, the objects it can produce, and the auth boundary it crosses.
execution
A run leaves a trace: inputs, capability or system version, commands, output hashes, and failure state when available.
review
Outputs are source material, checks, or reviewable changes until a reviewer accepts a frontier event.
record
Track records are derived from frontier provenance. They show activity and lineage, not correctness by themselves.
A capability record should make its boundary visible before an agent runs it: source boundary, output lanes, what it reads, what it declares as output material, what can fail, when it was checked, which agents rely on it, and which work path it enters.
Signals make the engine inspectable: status boundaries, auth scope, unused procedures, missing verification, and registered capabilities that need review before new runs rely on them.
No active signals in this view. The record has no visible queue, blocker, or validation item under this index.
Engine primitives
These are the capability-layer objects that keep agents, procedures, checks, source connectors, and generated context inspectable before review accepts a frontier event.
source connector
A source connector names the external surface it touches, the objects it can fetch, freshness policy, and authority class.
context pack
A run should list the frontier, sources, exclusions, prompt hash, capability versions, and index freshness it relied on.
derived index
Indexes are content-addressed projections over records. They can guide review, but they do not become the record.
procedure graph
Procedures should expose bound checks, harnesses, examples, expected outputs, permissions, and known failure modes.
impact query
Impact views should trace affected findings, capabilities, procedures, agents, proof packets, atlases, and constellations.
promotion review
Generated facts, graph edges, and summaries need a review action before they become frontier events.
context filters
Agents should expose frontier, workspace, organization, user, and external-source include or exclude controls.
episode log
Capability calls, failed attempts, commands, outputs, and observations are useful history, not hidden authority.