Contracts
Normative specifications — documents that say what must be true. These answer “what does X have to satisfy?”
If you need conceptual background, see concepts/. If you need a step-by-step guide, see guides/.
What NOT to put here: implementation recipes, tutorials, or exploratory ideas. A contract specifies; it does not explain. If a document mostly explains, it belongs in concepts/.
Contents
| Document | What it specifies |
|---|---|
| runtime-adapter-contract.md | What any runtime adapter must honor |
| delivery-output-contract.md | What a generated delivery output must reveal |
| bootstrap-generator-contract.md | What a bootstrap generator must receive, emit, and preserve |
| delivery-tooling-boundaries.md | What delivery tooling may and may not do |
| readiness-gates-spec.md | When a slice is ready to continue, review, hand off, or stop |
| context-resource-telemetry-spec.md | Telemetry surface for resource-aware operations |
| context-surface-registry.md | Minimum metadata, loading boundaries, freshness and evidence for surfaces that influence agent behavior |
| system-state-registry.md | Compact per-repository first-load state, authority boundary, update triggers and Restart Package relationship |
| observation-governance-contract.md | Minimum structured, source-backed and recoverable observation record |
| slice-telemetry-model.md | Minimal model for recording slice-level telemetry |
| visual-operations-event-model.md | Normalized, source-referenced events for read-only visual projection |
| work-slice-visual-state-contract.md | Presentation lanes and derived Work Slice card state without a new lifecycle |
| visual-ops-privacy-boundaries.md | Metadata-first privacy rules for cockpit views, traces, telemetry, and exports |
| work-slice-spec-bundle.md | Optional spec bundle for slices that need pre-execution clarity |
| intent-to-evidence-extension.md | Optional human-owned Intent, Expectations, Guessing Risk, evidence mapping and reconcile inside a Work Slice |
| coding-safety-plan-profile.md | Minimum coding plan profile for base state, scope, verification, drift, rollback, stop conditions and human merge decision |
| cognitive-documentation-closure-extension.md | Proportional finalization review for preserved intent, human understanding, documentation coherence and technical escalation |
| durable-decision-finalization-context-prompt.md | Accepted durable decision: require finalization context prompt at slice close |
| consumer-project-overlay.md | How a consumer project instantiates the operating overlay (ops/ai/ + harness shims). Reference example: examples/consumer-overlay-minimal/ |
| knowledge-source-contract.md | What every knowledge source must satisfy to be governed by the Knowledge Governance Layer |
| knowledge-pack-manifest.md | YAML manifest schema for a knowledge pack on disk |
| skill-knowledge-dependency-contract.md | How a skill declares knowledge it needs without binding to a specific source |
| source-precedence-policy.md | How conflicts between knowledge sources are resolved |
| restricted-knowledge-usage-policy.md | Usage rules for confidential, restricted, and regulated sources |
| knowledge-audit-log-spec.md | Minimum audit fields when a knowledge source influences output |
| sensitivity-vocabulary-mapping.md | Canonical sensitivity taxonomy and how project extensions map local labels to it |
| reference-intake-adoption-contract.md | Minimum intake, layer mapping and adoption decision record before external references influence AletheIA or Adaptive Skills |
| skill-evolution-validation-contract.md | What a skill evolution experiment and its validation evidence must satisfy to be governed |
| skill-catalog-governance-contract.md | How AletheIA governs skill selection, rejection, override, proposal decisions and catalog-review observations without becoming the skill authoring system |
| independent-validation-hardening-contract.md | Minimum critic context, evidence-to-expectation gate, validation review record and blind-review constraints for proportional independent validation |
| runtime-effort-governance-contract.md | How an agent decides runtime effort for a work slice: start, escalate, de-escalate, stop, and human checkpoint |
| agent-harness-governance-extension.md | How the harness validates, authorizes, executes, budgets, and returns structured observations for model-proposed actions |
| agent-harness-contract.md | The per-task declaration: autonomy, allowed tools/skills, gates, sensors, rollback, human review, context policy |
| capability-routing-reconciliation.md | Canonical mapping between capability, skill, tool, agent/subagent, execution vehicle, execution pattern, AHC/AHGE and read-only Observatory evidence |
| agent-role-contract-reconciliation.md | How professional projections such as Software Engineer and QA/Governance Reviewer map to portable roles without creating a second role catalog |
| design-system-intelligence-pilot.md | Minimum source-backed review record for bounded Design System Intelligence pilots such as Pulso, without scanners or promotion authority |
| human-expertise-learning-contract.md | How scoped human expertise and evidence-based learning are recorded without automatic authority or self-evolution |
| policy-verdicts.md | The verdict vocabulary (allow/deny/require_approval/transform/log_only) and its mapping to harness decision values |
| agent-action-audit-record.md | Minimum audit fields proving skill → tool → verdict → evidence → approval |
| execution-pattern-selection.md | How a task records its selected execution topology and required controls |
| orchestration-contract.md | What an orchestrated execution must declare before stages run |
| loop-readiness-gate.md | Minimum readiness record before a Work Slice may use loop-shaped execution without creating a scheduler or runtime |
| loop-state-contract.md | Minimum state shape for recurring or looped work |
| objective-gate-policy.md | Objective stop/gate requirements before loops can run safely |
| maker-checker-policy.md | When separate generation and verification roles are required |
| execution-audit-record.md | Pattern-level audit view over existing AHGE evidence |
Operationalized by security checklists
The restricted-use and audit contracts above are specifications. The per-task
checklists and policies that apply them at runtime live in docs/security/
(data-leakage, prompt-injection-in-sources, data-poisoning, logs-and-handoffs,
human-review-criteria).
Bootstrap contracts — note on relationship
bootstrap-generator-contract.md and delivery-output-contract.md are complementary, not duplicates:
- Generator contract: spec of the process (what the tool receives and emits)
- Output contract: spec of the artifact (what the produced package must reveal)