Glossary

A composition component that defines the identity-specific semantics of the produced artifact, such as an Agent Skill, Website, or Web application, while reusable capabilities and lifecycle concerns remain separate authorities.

Repository usage: Website and Web application are sibling artifact identities in the current production catalog. Both may require the shared foundation.web baseline, but content/document orientation versus interactive application tasks determines artifact identity rather than static/dynamic rendering, runtime, or PWA selection.

Related: Composition component, Artifact contract

The exact immutable product source revision named for release production, against which authoritative proofs run and to which approved release evidence and the resulting release bundle are bound.

Repository usage: This is the product release-candidate revision in the Composition release lifecycle, not a generic pull-request candidate or Policy toolchain promotion candidate. The stable term ID predates the Composition authority migration and is retained for the surviving concept.

Related: Release evidence, Release bundle, Composition release readiness

An artifact-neutral composition component that adds an optional product capability such as an implementation runtime, packaged CLI, MCP interface, MCP Apps extension, standalone browser interface, or headless service.

Related: Composition component, Implementation runtime, Implementation runtime decision record, Model Context Protocol

The single resolved Composition component recorded as the owner of a materialized destination. It identifies which component claims that destination and is independent of the destination's ownership mode; owner transitions are never inferred automatically.

Related: Composition component, Material ownership, Ownership mode, Composition lock

The machine-readable role assigned to every Composition component. It explains whether the component supplies a shared required base (foundation), defines what is being built (artifact), adds an optional observable behavior (capability), manages the artifact over time (lifecycle), establishes repository authority, history, and projection structure (topology), or defines local checkout materialization (workspace).

Related: Composition component, Foundation component, Artifact component, Capability component, Lifecycle component, Repository topology component, Workspace component

A closed reusable source authority with a component role: foundation, artifact, capability, lifecycle, topology, or workspace. Its descriptor declares dependencies, conflicts, materialized files, ownership modes, and any contract registrations used by deterministic composition.

Related: Component role, Foundation component, Artifact component, Capability component, Lifecycle component, Repository topology component, Workspace component, Composition recipe

The positive integer compatibility boundary declared by a Composition component descriptor. A managed update cannot cross a version change, while an explicit upgrade may; same-version descriptor drift is rejected as an invariant violation.

Repository usage: A Composition component version is not Semantic Versioning and does not encode major/minor/patch significance.

Related: Composition component, Composition update, Composition upgrade

A product or artifact repository that consumes Composition recipes/components and may carry Composition-managed state, materialized contracts, or consumer-owned seed content. It is the target of Composer operations rather than the Composition source-authority repository itself.

Repository usage: Consumer refers to the repository or its maintainer consuming Composition, not to an application end user or customer.

Related: Composition recipe, Composition lock, Initial composition, Composition update, Composition upgrade

The deterministic .template-composition/lock.json resolved-state record written last by the composer. It binds the exact composition source revision, configuration bytes, resolved components, descriptor digests, material destinations, owners, ownership modes, and materialized-byte digests.

Related: Composition recipe, Material ownership, Component owner, Ownership mode, Managed material, Seed material, Generated material

A consumer-facing artifact recipe that selects exactly one artifact component and defines which reusable capability or lifecycle components are required, defaulted, or available for explicit selection.

Related: Composition component, Composition lock

The implementation-evidence lifecycle decision that a product-mode evidence graph is ready for release production: required targets and requirements are covered and every proof required by the selected release gates is verified rather than deferred or missing.

Repository usage: Passing Composition release readiness permits the Composition release producer to proceed; it does not by itself prove packaging, signing, deployment, external artifact identity, or post-deployment success.

Related: Implementation evidence, Product mode, Candidate revision, Release evidence

A managed Composer reconciliation that preserves the normalized consumer intent already recorded in lock schema version 2 while reconciling that intent against the current descendant Composition source revision.

Repository usage: Update does not accept replacement configuration and cannot cross a Composition component-version compatibility boundary; the size of the source change does not determine whether an operation is an update.

Related: Composition consumer repository, Composition lock, Composition upgrade, Composition component version

A managed Composer reconciliation that consumes explicit replacement consumer configuration and may change recipe selection, includes/excludes, component parameters, or cross a declared Composition component-version compatibility boundary.

Repository usage: Upgrade means explicit replacement intent or a compatibility-boundary crossing in Composer semantics; it is not defined merely by a source change being large or major.

Related: Composition consumer repository, Composition lock, Composition update, Composition component version

A stable versioned identity for one registered contract concern, with its active or retired state, current schema version, contiguous version history, migration path, document/schema locations, and evidence relationship maintained through contract evolution.

Repository usage: The concept originated in the former Webapp authority but now applies through the artifact-neutral Composition contract-evolution lifecycle; the historical stable ID is retained because the concept itself survives.

Related: Contract manifest, Lifecycle component

The deterministic generated contracts/manifest.json registry built from contract registrations in the resolved component closure. It identifies active contract documents, schemas, purposes, version histories, and migrations without being a handwritten source file.

Related: Generated material, Lifecycle component, Release bundle

A shared mandatory baseline introduced through an artifact component dependency. Foundations are not consumer-selectable product capabilities and cannot be directly included by a recipe.

Related: Component role, Artifact component, Composition recipe

Materialized content produced deterministically by an allowlisted declarative generator from resolved composition authorities rather than copied from one source file. Its bytes remain composition-managed and digest-bound in the lock.

Related: Composition lock, Material ownership, Ownership mode, Managed material, Seed material, Contract manifest

An artifact-neutral lifecycle contract that maps artifact-defined contract targets to repository-local implementation boundaries, positive and negative proofs, authoritative command definitions, and release gates. It defines what must be proved and run but does not record candidate execution itself.

Related: Release evidence, Artifact contract, Lifecycle component

The implementation ecosystem and operational choices used to build and run a composed artifact, including its language/runtime, runtime version, dependency and package workflow, exact commands, environment, distribution, and deployment.

Related: Capability component, Implementation runtime decision record

The consumer-owned RUNTIME.md decision record materialized by capability.runtime. It records the selected implementation runtime, dependency workflow, exact commands, protocol selections, environment, distribution, and deployment lifecycle without belonging specifically to Skill, Website, or Webapp semantics.

English aliases: Runtime decision record

Repository usage: Runtime is an optional artifact-neutral capability. A Website may have a maintained server runtime and a Webapp may be statically hosted; runtime selection therefore must not be used to classify Website versus Web application product identity.

Related: Implementation runtime, Capability component

The first Composer materialization of a not-yet-managed consumer repository from explicit consumer configuration. It requires no existing Composition lock, refuses unsafe destination replacement, and writes the lock last to establish managed Composition state.

Repository usage: Initial composition is one explicit Composer operation mode; it is not a generic project initialization step.

Related: Composition consumer repository, Composition lock, Composition update, Composition upgrade

A content-addressed Composition lifecycle record that preserves validated planning or product contract state, parent/sequence linkage, and selected validation snapshots so later transitions can be checked against the recorded baseline.

Repository usage: The local checkpoint hash chain is not a trusted timestamp or external attestation and cannot by itself prove real-world chronology against wholesale history replacement.

Related: Planning mode, Product mode, Lifecycle component

An artifact-neutral composition component that adds product lifecycle machinery such as resolved-state validation, contract evolution, implementation evidence, release evidence, or release handoff.

Related: Composition component, Contract manifest, Implementation evidence, Release evidence, Release bundle

Materialized content whose composition source remains authoritative after initial application. Consumer-time validation requires its current bytes to continue matching the composition lock digest.

Related: Composition lock, Material ownership, Ownership mode, Seed material, Generated material

The Composition rule that assigns every materialized destination exactly one component owner and one ownership mode. The owner identifies which resolved component claims the destination, while the mode determines whether Composition retains authority over its bytes or transfers content ownership to the consumer.

Related: Component owner, Ownership mode, Composition lock

The per-destination lifecycle classification recorded as managed, generated, or seed in the Composition lock. It determines byte authority after materialization: managed and generated content remain Composition-controlled, while seed content transfers to the consumer.

English aliases: ownership modes

Related: Material ownership, Managed material, Seed material, Generated material, Composition lock

The narrow Composition lifecycle state used after explicit product requirements and their intended machine-contract targets are known but before concrete implementation-evidence records exist. Planning mode keeps implementation records and release execution claims incomplete while preserving stable requirement identity and required proof kinds.

Repository usage: Planning mode is a contract state, not a synonym for the whole project-planning phase.

Related: Template mode, Product mode, Implementation evidence, Composition release readiness

The Composition lifecycle state in which the concrete implementation and evidence graph is active: product requirements link to implementation boundaries, proofs, authoritative commands, and release gates according to the selected contracts.

Repository usage: Product mode does not mean implementation complete, release ready, released, or deployed. Product-mode proofs may still be deferred or otherwise incomplete until the separate release-readiness contract passes. This stable term ID predates the Composition authority migration and is retained for the surviving concept.

Related: Template mode, Planning mode, Implementation evidence, Composition release readiness

An artifact-neutral deterministic handoff contract that binds an approved candidate revision to the exact current bytes of the active registered contract set transferred to the next system.

Related: Contract manifest, Release evidence, Lifecycle component

An artifact-neutral revision-specific record that binds one exact candidate revision to completed authoritative command and release-gate results, execution provenance, and the resulting release decision.

Related: Implementation evidence, Release bundle, Lifecycle component

An artifact-neutral composition component that declares and materializes repository authority, history, and projection structure (such as Hub-and-Orphan) rather than artifact identity, capability, or lifecycle behavior.

English aliases: Topology component

Related: Composition component, Component role, Composition recipe

Materialized initial content whose ownership transfers to the consumer repository after composition. The file must remain present, but consumer edits are allowed to diverge from the initial lock digest.

Related: Composition lock, Material ownership, Ownership mode, Managed material, Generated material

A Skill-specific resource pattern describing whether a concrete Agent Skill is instruction-only, knowledge-augmented, asset-driven, or script-assisted. Application runtime and public interfaces are composition capabilities rather than Skill profiles.

Related: Policy profile, Skill template scaffold, Capability component

The uncustomized Agent Skill seed identified by the reserved template-scaffold sentinel. The sentinel is not a fifth concrete Skill profile and must be replaced before the repository is treated as an operational Skill.

Related: Skill profile, Artifact component

The Composition lifecycle state in which a selected contract carries no active product requirement or concrete implementation claim. Template mode provides scaffold/default contract structure only; it is not a claim that a repository is merely a template or that a concrete product has been validated.

Repository usage: This stable term ID predates the Composition authority migration and is retained because the same lifecycle concept survives under the current artifact-neutral Composition model.

Related: Planning mode, Product mode, Implementation evidence

An artifact-neutral Composition component that declares local-checkout and workspace materialization semantics independently from repository authority, history, and projection topology.

Related: Composition component, Repository topology component

The bounded Integration-generated guided-navigation graph v2 of Provider-branch-owned index.md navigation metadata from exact reviewed Provider branch revisions. Its provider discovery root is the authority root index.md; each reachable index retains its source blob identity. It preserves Provider branch grouping, order, labels, and descriptions without turning provider indexes into a publication catalog or replacing Integration-owned reader navigation. Site may render this schema-versioned machine-readable graph at /guided/.

Related: Integrated publication, Provider branch, Publication catalog, Publication source lock

The Integration-owned publication model assembled from reviewed exact revisions of independently owned Provider branch histories without merging those histories or transferring ownership of their canonical content.

Related: Provider branch, Publication catalog, Publication source lock

A repository-internal primary Git branch, currently composition or policy, that owns canonical content supplied as an independently versioned input to the Integration publication model.

Summary: One of the repository's composition or policy content-source branches used as an input to Integration publication.

Repository usage: In Integration publication terminology, Provider branch refers only to these internal Git content-source branches. It does not mean a cloud provider, LLM or API provider, identity provider, or other external service provider. Integration assembles provider sources and Site renders the result; neither is a Provider branch. Policy documentation also uses Provider / toolchain layer in its own Policy-specific architecture, which is a separate use of provider terminology.

Related: Publication catalog

A declaration owned by a Provider branch that lists the canonical publication inputs Integration is permitted to integrate.

Related: Provider branch

An Integration-owned binding in publication-sources.json from a Provider branch publication to a reviewed full 40-character commit SHA used as an immutable build input. Mutable branch names, tags, and abbreviated SHAs are not valid publication source locks.

Related: Provider branch, Integrated publication

A requirement whose meaning depends on a particular agent, platform, protocol, command surface, renderer, or output format. It adapts or presents semantics instead of defining application-independent shared policy.

Related: Policy renderer, Artifact contract

A requirement class that defines what a produced Skill, Web application, CLI, library, service, or other artifact must contain or do. Artifact contracts belong to the produced artifact rather than to shared coding-agent operating policy.

Related: Adapter/renderer requirement, Explanatory material

The trust-seed role of the installable skills/agent-policy package when it is used to onboard an unmanaged repository. Its runtime manifest selects one reviewed immutable Policy toolchain revision, binds that revision's runtime dependency lock by SHA-256, and exposes a closed bootstrap route set with no migration-finalization route. After adoption, the same skill follows the managed repository's .agent-policy.lock instead of switching to a separate bootstrap package.

Related: Stable release descriptor, Promoted toolchain revision, Managed repository, Policy adoption

Artifact- and engine-independent policy content selected only for a particular operational context, such as pull-request review or external artifact intake. It is policy content, not the Policy context selector: a Policy context is the named semantic authority boundary that selects profiles, repository-local policy, and overrides; each output separately references both a context and a renderer.

Related: Policy context, Shared policy

Rationale, examples, history, proposals, and other non-normative text that explains policy or artifact decisions without itself establishing a normative policy rule or artifact contract.

Related: Artifact contract

The Policy adoption strategy selected for an unmanaged-empty repository, where no handwritten primary agent instructions require migration. When explicitly applied it may use the hidden init primitive internally and can create normal managed state directly without a staged adoption-state transaction.

Related: Policy adoption, Migration adoption, Managed repository

A product repository that Policy onboarding inspection classifies as managed because the canonical .agent-policy.yml path resolves to an existing regular file. Managed repositories use normal validate, render, and check operations through the same installed agent-policy skill, whose runtime selection follows .agent-policy.lock. The classification itself does not assert that configuration semantics have already passed those validations, and partial or conflicting generated state is classified separately as inconsistent.

Related: Policy profile, Policy context, Repository-local policy, Bootstrap trust seed, Policy adoption, Policy render, Policy validate, Policy check

The Policy adoption strategy selected for an unmanaged-existing repository. Existing instructions remain authoritative while preparation records protected sources and generates a non-conflicting preview; a later explicit finalize --apply transaction performs cutover only after semantic review.

Related: Policy adoption, Fresh adoption, Managed repository

The user-facing first-time onboarding operation that inspects an unmanaged repository and derives either fresh adoption or migration adoption from repository state before any supported mutation. Installing the agent-policy skill provides the entry point but does not itself adopt the target repository.

Related: Bootstrap trust seed, Fresh adoption, Migration adoption, Managed repository

The read-only managed-repository operation that verifies the current configuration, semantic inputs, .agent-policy.lock, and generated outputs agree. It detects missed regeneration and manual changes to generated outputs but does not regenerate them.

Related: Managed repository, Policy render, Policy validate

A named semantic authority boundary in agent-policy configuration that selects shared policy profiles, repository-local policy files, and any explicit overrides. Outputs reference a context rather than selecting policy semantics independently.

Related: Policy profile, Policy renderer, Context policy, Repository-local policy, Policy override

A shared-policy source file that owns one independently applicable normative rule and one stable rule ID, with metadata such as severity, override permission, and deterministic order plus optional rationale and examples.

The mechanism by which a repository-local rule intentionally replaces an overridable shared rule with the same stable rule ID. The containing policy context must record that exception in an explicit override declaration with a non-empty reason, while the repository-local policy file remains the source of the replacement rule body.

Related: Policy context, Shared policy, Repository-local policy

A named ordered selection of shared policy modules that can be selected by a managed repository or policy context as part of its semantic policy input.

Related: Policy module, Skill profile

The mutating managed-repository operation that composes the current accepted shared and repository-local Policy inputs and regenerates the configured outputs together with .agent-policy.lock. Generated outputs are changed through render rather than edited directly.

Related: Managed repository, Policy validate, Policy check

A presentation adapter that renders the semantic rules selected by a policy context into a caller-facing output format without selecting, adding, removing, or overriding policy rules.

Related: Policy context, Adapter/renderer requirement

The read-only Policy operation that validates .agent-policy.yml and its referenced semantic inputs, including schema shape, known profiles, policy files, rule identities, overrides, and repository path safety. A successful validation does not assert that generated outputs match the current lock and inputs.

Related: Managed repository, Policy render, Policy check

The reviewed candidate full commit SHA selected by Policy promotion and written into both the stable release descriptor and the single-skill runtime manifest. It is a strict ancestor of the later promotion state, avoiding recursive self-reference.

Related: Stable release, Stable release descriptor, Bootstrap trust seed

Policy owned by a managed repository for local facts, invariants, justified extensions, or explicit permitted overrides. It supplements shared semantics instead of restating shared rules merely for convenience.

Related: Policy context, Shared policy, Policy override

Artifact- and engine-independent operating behavior that is generally applicable and is authored in the policy branch as canonical shared semantics rather than copied into consumer repositories as an independent handwritten authority.

Related: Policy module, Policy profile, Context policy, Repository-local policy

The executable Policy toolchain release currently selected by the stable release descriptor. It may intentionally lag the advancing policy branch and is identified by the promoted toolchain revision rather than by the later promotion-state commit.

Related: Stable release descriptor, Promoted toolchain revision

The committed release/toolchain.json record for the stable channel that binds the Policy toolchain repository and exact promoted revision together with synchronized contract versions and verifier requirements.

Related: Stable release, Promoted toolchain revision, Bootstrap trust seed