Agentic Architecture Audit — Agent Specification v3.5

Version: v3.5 Specification date: 2026-06-10 Status: Operator-to-agent instruction document Scope: Project-agnostic and tooling-agnostic Lineage: Supersedes Agentic Architecture Audit Specification v3.4. Preserves all v3.4 behavior while adding: a per-cycle id-durability discipline for findings and fitness functions (Phase 10, §8.11/§8.12 optional cycle field); typed citation provenance — observed_at, valid_until, and evidence_lane extending the citation schema (§8.1, Phase 10.5); named claimed-automation-absent and instruction-reference-broken flags on the contract surface (Phase 4, §8.5); a review-power proportionality matrix and inversion flag (Phase 6, §8.7, §9.9); a regression-trap eval-suite mode (Phase 9, §8.10); metalanguage containment — audit-internal taxonomy is never exported into project vocabulary, with the Phase 1 collision check extended to audit-taxonomy collisions (§3, Phase 1, Phase 5, §8.2); operating-agent model/CLI baseline and alias-resolution drift checks (Phase 6, §8.7); an agent-memory truth-maintenance evidence target (Phase 5, §8.6); a negative-self-test rule for implemented fitness functions (Phase 10, §8.12, §11.11); and a standing-decision-ledger evidence target (§11.10). Additive only: v3.4 audits remain valid. Profiles from Project Profile Discovery Directive v1.5 are consumed unchanged; Directive v1.6 adds optional discovery fields this specification consumes when present. The rationale is recorded in adr/0004-evidence-discipline-and-enforcement-honesty.md.

0. Purpose

Audit a codebase, workspace, platform, or automation system for 2026-level structural alignment.

The audit asks whether the system has clear boundaries among:

domain policy and invariants;
application orchestration;
agent or automation runtime;
machine-readable contracts;
adapters and external integrations;
state, memory, and artifacts;
authority, approval, and blast-radius controls;
observability, evaluation, and governance.

The audit produces evidence-backed, machine-verifiable findings and candidate fitness functions. It does not refactor code, reorganize files, silently repair drift, or decide product conventions for the operator.

This specification is intended to work across languages, frameworks, repositories, agent platforms, and hosting environments. Tool names appear only as examples of enforcement categories; they are not requirements.

The audit treats modern protocol objects as first-class architecture, not as vendor trivia. If a repository exposes MCP, A2A, workflow-description, remote-agent, hosted-tool, computer-use, browser-use, or background-agent surfaces, the audit inventories the advertised contracts, lifecycle states, authority model, and provenance behavior separately instead of collapsing them into a generic "tool" or "runtime" bucket.

Scope boundary. The audit assesses architecture and the repo's agent-operating contracts and authority — not developer-agent workflow preference (worktree habits, local navigation, IDE affordances, CLI ergonomics), unless such an item defines authority, exposes a contract, automates a side effect, or is enforced as a fitness function. The product's own exposed CLI/SDK/MCP surfaces remain in scope.

1. Operating Model: Directive-as-Handoff

The audit operates as a directive series. Each directive moves one decision point forward and produces one or more durable artifacts. Operator decisions are captured in directive text. Agent execution is captured in files under the dated audit directory. The combined record is the audit.

The agent must treat chat as a control plane, not as the audit record. Phase gates, evidence, findings, scoring, and decisions belong in artifacts.

1.1 Snapshot model

The audit is anchored to a dated project profile snapshot.

The profile states what the repository, operator, and governance documents claim at a point in time.
The audit tests those claims against source evidence.
The audit also performs a late smoke-test against the current working branch before findings ship.
When the snapshot and current branch disagree, the disagreement is recorded as drift rather than silently reconciled.

1.2 Audit mode

Every audit declares one of:

first-cycle — no prior audit on this project. Establishes conventions, branching, ADR templates, halt-recovery patterns. Highest directive overhead.
steady-state — prior audit exists. Inherits cycle-history conventions; runs all phases against current evidence.
focused-diff — prior audit exists and the profile diff shows narrow change. Runs only phases whose inputs changed materially. Default fallback is steady-state if eligibility is unclear.

The mode is recorded in 00-scope.md and SUMMARY.md. The first cycle's overhead amortizes; later cycles consume the previous dated profile, the profile diff, the cycle history, and prior audit findings instead of restating them in directives. Prior-cycle citations carry their own freshness window where the optional §8.1 freshness fields (observed_at, valid_until, evidence_lane) are recorded, so steady-state and focused-diff consumers see per-citation staleness instead of trusting only the prior cycle's ship-time re-verification.

2. Inputs

2.1 Required inputs

profile/<date>/project_profile.yaml produced by the profile directive.
profile/<date>/profile-discovery.md.
Operator-provided scope confirmation or a clear statement that profile scope is authoritative.
Current repository or workspace read access.

2.2 Conditional inputs

If present, the audit must also consume:

profile/<date>/profile-diff.md and/or profile-diff.json;
profile/cycle-history.md;
prior audit summaries;
remediation plans and PR summaries from previous cycles;
ADRs created or superseded since the last audit;
operator-specified strategic themes for prioritization.

2.3 Strategic themes

The operator may provide one or more strategic themes that change priority weighting in Phase 10. Themes are project-agnostic strings; common examples include:

sdk-extraction — preparing for licensing, white-label, or public SDK release.
multi-tenant-isolation — adding tenant boundaries to an existing system.
regulatory-readiness — preparing for SOC 2, HIPAA, FedRAMP, or similar.
agent-safety-hardening — tightening authority, approval gates, and provenance.
eval-coverage — closing eval gaps before launch.
cost-attribution — shipping per-tenant or per-feature billing.
agent-runtime-consolidation — reducing tool sprawl and clarifying boundaries.
legacy-migration — migrating off a deprecated framework or pattern.
agent-operability — ensuring the repo exposes a canonical cross-agent instruction contract, committed agent-authority configuration where applicable, enforced operating guardrails, and source-controlled customization layers (skills, hooks, plugins, protocol-server configuration) so supported repo-operating agents can navigate and operate it.

If a theme is supplied without an explicit dimension mapping, use the default from the table in §11.12. A strategic theme is not a finding; it is a weighting signal. The agent must not invent a theme. If none is provided, all findings record strategic_relevance: none.

3. Prime Directives

Evidence-first. No finding is valid without a citation: file path, line range or glob, evidence excerpt, and the command or read operation that produced it. Unsupported findings are rejected.
Classify before judging. Use the taxonomy in §6. If a subject resists classification, record unclassified with a reason instead of inventing a category.
Claims are not confirmations. Folder names, manifest names, and governance labels are claims. The audit tests them.
Halt on contradictions. Do not guess through structural ambiguity. Produce a halt artifact when halt conditions apply.
Scope before depth. Phase 0 confirms scope and excluded regions. Do not descend into deep analysis before scope is stable.
Audit, do not restructure. Do not recommend folder moves during discovery phases. Structural moves, renames, and remediation belong to a separate planning directive.
Artifacts are the record. Each phase produces a named file under audit/<date>/. The operator reviews files, not chat summaries.
Read-only by default. Do not edit source code. The operator may explicitly grant write authority for audit artifacts and, if separately stated, ADR drafts.
Boundary declarations are local. Each phase states what the agent must resist while performing that phase. Honor phase-local boundaries at the decision point, not only global prohibitions.
Separate current-state findings from future-state safeguards. A finding describes the present system. A fitness function prevents recurrence. They cross-reference but do not share IDs.
Smoke-test before shipping. Findings must be rechecked against the current working branch before SUMMARY.md is written.
Surface calibrated caveats. Distinguish substantive deviations from cosmetic deviations and exact matches. Honest caveats are audit signal, not noise.
Protocol surfaces are first-class. MCP, A2A, workflow-description, callback, hosted-tool, and remote-agent surfaces are classified by their concrete objects and lifecycle states, not only by vendor or package name.
Authority is a matrix. Approval presence alone is insufficient. Record approval mode, deny/ask/allow precedence where applicable, bypass modes, protected-path behavior, secondary credential acquisition, network/callback authority, and enforcement evidence.
Version-derived companions. Kickoff prompts, friendly explainers, schemas, examples, and manifests derived from this specification must declare the source spec version/date they target. Inconsistency with this authority spec is documentation drift.
Contain the audit's own metalanguage. The audit's classification vocabulary (store classes, surface types, flag names) is audit-internal taxonomy, never recommended project vocabulary. Where the profile declares project-banned terms, audit prose artifacts restate them in the project's canonical vocabulary; taxonomy values remain legal inside machine-readable schema fields.

4. Halt and Recovery

4.1 Halt conditions

Stop and produce audit/<date>/halt.md when any of these occur:

Two or more ADRs contradict each other on a structural question material to the audit.
A directory or manifest claims a bounded context but contains only adapters, only generated artifacts, or only contracts with no domain behavior.
The same business term has conflicting semantics in two regions both classified as domain or policy-bearing.
A claimed bounded context has no identifiable authority basis (authoritative store, event source, external authoritative system, or explicit stateless justification).
The repository exceeds the profile scope and no operator-approved bounds exist.
Tool, action, or skill definitions exist but no schema, signature, manifest, or authority declaration can be located.
Runtime prompts contain hard-coded business values that appear nowhere else in policy, configuration, or domain code.
Agent or automation runtime can perform write actions but approval policy is absent or unclear.
A protocol surface advertises capabilities, skills, resources, prompts, roots, tasks, callbacks, or remote actions but no matching authorization, scope, schema, or lifecycle declaration can be located.
Background, paused, resumable, streaming, durable, or long-running execution can cause side effects but lacks an explicit lifecycle contract, resume-state handling, approval path, or callback/webhook authentication model.
Operator-granted authority is insufficient to read a region the audit depends on.
Profile evidence and repository evidence contradict in a way that changes scope, stack, governance precedence, or claimed bounded contexts.
Phase 10.5 smoke-tests reveal that more than one third of findings cite stale evidence — the audit has drifted too far from current development to ship; produce audit/<date>/halt-stale-evidence.md and request a fresh profile snapshot.
The directive package supplied to the audit contains conflicting authority texts (for example, kickoff prompt versus audit spec) and no precedence statement resolves the conflict.

4.2 Halt artifact contents

halt.md must include:

halt condition;
phase where it occurred;
evidence citations;
why the contradiction blocks the audit;
the single operator decision needed to resume;
downstream phases that are blocked;
downstream phases that may safely continue, if any.

4.3 Halt-recovery state machine

A halted audit may resume only through this sequence:

Halt. Agent writes (and, if commit authority exists, commits) the halt artifact. Stops downstream phases.
Investigation. Operator and/or agent gathers missing context. Investigation artifacts are appended to the halt file or written under audit/<date>/halt-investigation/.
Rescope. Agent proposes one or more scoped recovery options (close, rescope, split). Do not rewrite the original finding as if the halt never happened.
Adjudicate. Operator chooses one option in directive text.
Resume. Agent continues from the earliest affected phase and records the recovery path in SUMMARY.md.

This pattern applies equally when remediation work later triggers a halt (e.g., a Wave 2 PR rescope). Naming the state machine here lets it run the same way at audit time and at remediation time.

5. Target Architecture Model

This model is a reference for classification and scoring. It is not a mandate to refactor.

5.1 Planes

Domain. Invariants, policies, value objects, domain services, domain events. Pure with respect to transport, persistence, UI, and provider SDKs.
Application. Use cases and workflows. Coordinates domain, adapters, transactions, authorization checks, idempotency, and side effects.
Agent or automation runtime. Model calls, tool selection, handoffs, loop control, guardrails, prompt assembly, planner/executor behavior, subagent dispatch, human approval checkpoints, and automation-policy routing.
Contracts. Machine-readable definitions for externally visible interfaces: HTTP, RPC, events, tools, resources, prompts, config, persisted records, retrieval metadata, plugin or extension manifests, OpenAPI/Arazzo/Overlay-style API and workflow descriptions, MCP tools/resources/resource templates/prompts/roots/sampling/elicitation metadata, protocol task lifecycles, protocol extension declarations (including server-delivered UI extensions), protocol registry and discovery metadata, A2A Agent Cards/skills/task-state contracts, callback or notification schemas, public SDK surfaces, cross-agent instruction contracts (a canonical AGENTS.md plus tool-specific bridge files), agent-skill packages (skill frontmatter, capability pre-approvals, and bundled executable assets), delegated-commerce mandates where an agent can initiate or approve payments, and provenance manifests for agentic outputs.
Adapters. Driving and driven integrations: routers, CLIs, workers, UI/API gateways, databases, queues, filesystems, cloud APIs, model providers, external services, device interfaces, retrieval indices, browser-use harnesses, computer-use sandboxes, and durable-workflow workers.
State, memory, and artifacts. Request-local state, session state, durable conversation state, long-term memory, retrieval corpora, retrieval indexes, generated artifacts, logs, evaluation datasets, checkpoint state, operator-authored persistent rules/memory, and operator decisions.
Authority and governance. Approval policies, approval-mode precedence, bypass/auto-approval modes, capability scopes, secrets, secondary credential paths, callback/webhook authentication, workspace roots, ADRs, rules, risk controls, access boundaries, and audit trail.
Observability and evaluation. Traces, logs, metrics, semantic conventions with version/stability status, audit logs, eval suites, golden datasets, regression gates, quality attribution, cost/latency tracking, runtime/action provenance, content provenance, and build/source provenance records.

Authority is cross-cutting. Every tool, adapter, action, agent, subagent, service, and entrypoint declares readable scope, writable scope, callable capabilities, and approval policy.

5.2 Alignment principle

The architecture is aligned when the system can answer, with evidence:

What business terms mean, and where their meanings are authoritative.
Which context owns each policy, data store, event, and external contract.
Which runtime entrypoints can cause which side effects.
Which schemas define external interactions.
Which prompts carry instructions only and which carry policy.
Which agent or automation actions require approval.
Which background, paused, resumable, streaming, durable, or callback-mediated paths can cause side effects and how they resume or complete.
Which state class a memory-like surface belongs to, who can delete it, and what policy controls retention.
Which telemetry attributes allow cost, latency, quality, provenance, and failure analysis.
Which fitness functions prevent known drift from recurring.

6. Classification Model

6.1 Primary categories

Apply in order; first match wins unless the subject is explicitly mixed.

Defines business invariants, policies, domain vocabulary, or domain events without framework dependency → domain.
Orchestrates use cases, transactions, workflows, or policy application across domain and adapters → application.
Contains model calls, prompts, tool choice, handoffs, guardrails, agent loops, subagent dispatch, planners, or automation runtime policy → agent-runtime.
Defines schema, IDL, API description, workflow description, overlay, event payload, tool signature, resource manifest, prompt manifest, MCP resource template/root/sampling/elicitation metadata, A2A Agent Card/skill/task contract, config schema, persisted format, public SDK/API shape, callback schema, or provenance manifest → contracts.
Accepts external calls, messages, user input, CLI input, webhooks, or UI events → interface.
Calls an external system, provider, device, database, queue, filesystem, model, or cloud service → adapter.
Provides platform capability with no domain semantics → infrastructure.
Stores state, memory, cache, index, or generated artifact → state.
Produces telemetry, audit records, eval records, provenance records, or quality metrics → observability.
Records decisions, policies-as-code, governance rules, risk controls, fitness functions, or skill/SOP files (SKILL.md, AGENTS.md, CLAUDE.md) → governance.
Renders or manages user interface behavior → interface-ui.
Cannot be cleanly classified → unclassified with reason.

6.2 Mixed classification

A module, file, package, or directory is mixed when it contains two or more categories whose co-location creates architectural ambiguity or enforcement difficulty.

Examples:

domain policy plus database calls;
prompt assembly plus durable writes;
API route plus business invariant;
tool definition plus undeclared ambient authority;
schema plus runtime migration side effects;
subagent definition plus tool implementation in the same module.

A mixed classification requires citations for each mixed concern.

6.3 Tie-breakers

A "service" that orchestrates and performs I/O is application — the I/O belongs in an adapter.
A router that validates business rules is interface — the rules belong in domain or application.
A subagent definition is agent-runtime; the subagent's tool implementations are adapter or application per their primary work.
A SKILL.md / AGENTS.md / CLAUDE.md file is governance. Among instruction files, AGENTS.md is the canonical cross-agent source; tool-specific files (CLAUDE.md, GEMINI.md, .cursor/rules) are bridges that should import or defer to it. The canonical↔bridge relationship is inventoried as a cross-agent instruction contract in Phase 4. A prompt template referenced from one is agent-runtime.
An agent-skill package's machine-readable surface — frontmatter metadata, capability pre-approvals (for example an allowed-tools grant), and bundled executable scripts or assets — is additionally inventoried as a contract in Phase 4 and as an authority surface in Phase 6. Its prose instructions remain governance and are checked in Phase 8.
Test code is classified by the subject under test, tagged kind:test.

6.4 Secondary tags

Use as many as apply:

bounded-context:<name>
authority:read-only | read-write | admin | privileged | sandboxed | computer-use | browser-use | filesystem-use | hosted-tool | remote-agent | callback-capable | unknown
durability:request-local | session | durable | long-term | derived | cache | index | artifact | checkpoint | unknown
surface:http | rpc | event | queue | tool | resource | resource-template | prompt | root | sampling | elicitation | completion | cli | ui | webhook | callback | file | device | sdk | workflow | a2a | agent-card | task | subagent | agent-skill | extension | ui-app | commerce | other
sync-model:sync | async | streaming | long-running | scheduled | batch | background | paused-for-approval | resumable | durable | event-triggered | unknown
approval-mode:deny | ask | allow | auto-approved | human-in-loop | blocked | none-required | unknown
provenance:runtime-action | content | build-source | unknown
owner:<team-or-person-or-unknown>
criticality:core | supporting | edge | experimental | unknown
lifecycle:stable | experimental | deprecated | legacy | unknown
versioning:semver | date | hash | schema-version | none | unknown
kind:prod | test | fixture | tool | generated | docs | governance
provenance:emits | consumes | passthrough | none

7. Phased Workflow

Phases run in order. Each phase has inputs, procedure, boundaries, outputs, and an exit check. The agent must not advance past a failed exit check.

Phase 0 — Scope, Snapshot, and Orientation

Inputs

profile/<date>/project_profile.yaml
profile/<date>/profile-discovery.md
profile/<date>/profile-diff.md, if present
profile/cycle-history.md, if present
prior audit/<earlier-date>/SUMMARY.md, if present
operator scope statement, if present

Procedure

Record profile date, audit date, current branch, current revision, and audit mode (first-cycle, steady-state, or focused-diff).
Enumerate in-scope units, deployables, workspaces, packages, services, libraries, automation surfaces, and governance artifacts from the profile.
Verify that all profile-cited paths still exist; record drift where they do not.
Record include and exclude paths.
Record strategic themes and affected scoring dimensions, if provided.
Pin reference-anchor versions and stability statuses needed for the run (§14), including protocol revisions when MCP, A2A, workflow-description, or semantic telemetry surfaces exist. The pinned protocol revision is the baseline against which Phase 4 records each protocol object's lifecycle status.
Check directive-set companion metadata if supplied (companions/kickoff-prompt.md, companions/explainer.md, manifest, examples). Record drift when companions target a different authority version.
Route profile audit-attention flags to Phases 1–10.
Identify previous-cycle conventions from cycle history that affect this audit.

Boundary declarations

Do not re-run profile discovery.
Do not expand scope merely because adjacent code is interesting.
Do not treat profile claims as audit findings until tested.
Do not silently discard profile drift; record it.
Do not treat companion docs as authority over this specification unless the operator explicitly says the audit spec is superseded.

Outputs

audit/<date>/00-scope.md
audit/<date>/00-scope.json
audit/<date>/00-reference-anchors.json

Exit check

Scope is bounded and audit mode is recorded.
Every routed audit-attention flag has a target phase.
Every profile path missing from the current branch is listed as drift.
Strategic themes are recorded or explicitly empty.
Required protocol, semantic-convention, and companion-version anchors are pinned or explicitly marked not applicable.

Phase 1 — Domain Vocabulary Extraction

Inputs

confirmed scope;
claimed bounded contexts;
glossaries, ADRs, docs, type names, schema names, events, commands, tools, UI labels, and prompts.

Procedure

Extract candidate domain nouns, verbs, event names, command names, policy names, state names, and external contract terms.
Group terms by unit and claimed context.
Identify terms appearing in multiple contexts with distinct definitions.
Identify multiple terms used for the same concept.
Record cited definitions and usage evidence.
Where the profile declares forbidden terms (conventions.forbidden_terms), check the audit's own taxonomy (§6 categories, store classes, surface types) against them and record each hit as an audit-taxonomy-collision (Prime Directive 16).

Boundary declarations

Do not infer a definition from a filename alone.
Do not resolve naming collisions by proposing renames in this phase.
Do not collapse technical terms into domain terms unless code or docs use them as domain language.

Outputs

audit/<date>/01-vocabulary.md
audit/<date>/01-vocabulary.json

Exit check

Every term has at least one citation.
Every collision candidate has citations for each conflicting use.
Every audit-taxonomy collision carries the project-side citation from the profile's forbidden-terms entry; the taxonomy side is identified by naming the taxonomy value and its section of this specification — it needs no project-file citation, and the §8.2 entry records the project term's definitions only.
Unsupported terms are removed or marked unclassified.

Phase 2 — Bounded Context Mapping

Inputs

vocabulary report;
claimed bounded contexts;
state and contract hints from profile.

Procedure

For each candidate context, fill a BoundedContext record (§8.3) with:

name;
status;
owner;
ubiquitous language;
authority basis (authoritative store, event source, external authority, stateless policy, or unknown);
inbound commands;
outbound events;
external dependencies;
consumed contracts;
produced contracts;
known policy responsibilities;
citations.

Classify status:

confirmed — at least three distinct evidence types support a coherent boundary.
candidate — one or two evidence types support the boundary.
claimed-only — docs or folder names claim it, but code evidence is insufficient.
rejected — claim contradicts evidence.
merged — evidence shows the claim is part of another context (note the merge target).
split — evidence shows the claim contains multiple contexts (note the split set).

Produce a context map showing calls, events, data dependencies, policy dependencies, and shared stores.

Boundary declarations

Do not upgrade claimed-only to confirmed without three independent evidence types.
Do not treat shared infrastructure as proof of one bounded context.
Do not recommend folder moves.
Do not decide ownership when ownership is absent; record unknown.

Outputs

audit/<date>/02-context-map.md
audit/<date>/02-contexts.json
audit/<date>/02-context-map.mmd

Exit check

Every claimed bounded context is confirmed, retained as candidate, rejected, merged, or split.
Every confirmed context has an authority basis.
No context map edge lacks evidence.

Phase 3 — Runtime Map

Inputs

context map;
profile deployable units;
entrypoint hints.

Procedure

Enumerate entrypoints: HTTP routes, RPC, CLI, UI actions, queue consumers, schedulers, webhooks, callbacks, event handlers, MCP tools, MCP resources, MCP resource templates, MCP prompts, MCP roots exposure, MCP sampling/elicitation/completion paths, protocol task-augmented or task-polling paths, A2A receivers, A2A Agent Card discovery paths, agents, subagent invocations, automation loops, durable-workflow handlers, background-agent triggers, batch jobs, device interfaces, and public SDK calls.
For each entrypoint, trace the call chain to the first external side effect (DB write, external API, queue publish, filesystem write, LLM call, tool invocation crossing an authority boundary).
Mark execution model: sync | async | streaming | long-running | scheduled | batch | background | paused-for-approval | resumable | durable | event-triggered.
For background, paused, resumable, durable, streaming, or callback-mediated paths, record lifecycle contract, resume state, timeout/retry behavior, notification/callback channel, and completion authority.
Identify loops where model, planner, script, or automation output feeds back into further actions. Record termination conditions: max-iterations, explicit stop tool, budget exhaustion, evaluator approval, human approval gate, scheduler bound, or timeout.
Identify subagent and remote-agent invocations (one agent calls another). Each invocation crosses an authority boundary; record both sides for Phase 6 consumption and any typed task/state contract for Phase 4.
Note human-in-the-loop approval gates and policy gates.

Boundary declarations

Do not assume an entrypoint is harmless because it is internal.
Do not stop tracing at an abstraction boundary if side effects continue downstream.
Do not infer termination from good intent; cite explicit stop, iteration cap, timeout, budget, or external scheduler bound.
Do not collapse subagent calls into "tool calls"; they have separate authority and separate evals.
Do not treat durable workflow handlers as cron — they have checkpoint state.
Do not treat a callback or push notification as a passive detail when it can resume work, deliver results, or trigger side effects.

Outputs

audit/<date>/03-runtime.md
audit/<date>/03-runtime.json
audit/<date>/03-loops/*.mmd, for the most important loops

Exit check

Every entrypoint has a traced chain or an explicit trace-blocked reason.
Every loop has a termination condition or is flagged.
Every write-capable runtime path is routed to Phase 6.
Every subagent invocation has caller and callee authority recorded.
Every background, paused, resumable, durable, or callback-mediated path has lifecycle evidence or is flagged.

Phase 4 — Contract Inventory

Inputs

runtime map;
profile contract hints;
public interfaces and integration surfaces.

Procedure

Locate externally visible and internally relied-upon contracts:

HTTP/RPC API descriptions;
workflow descriptions and overlays;
event payload schemas;
tool/action/skill schemas;
resource manifests;
MCP tools, resources, resource templates, prompts, roots exposure, sampling support, elicitation support, completion support, and authorization metadata;
protocol task contracts (durable or async request lifecycles advertised by a protocol surface, with their states, polling/notification behavior, and TTL or expiry semantics);
protocol extension declarations (negotiated extension identifiers and capability metadata), including server-delivered UI extensions (sandboxed app or iframe resources delivered by a protocol server);
protocol registry and discovery metadata (registry entries, well-known discovery documents, server cards, signed agent cards);
prompt manifests and parameter schemas;
configuration schemas;
cross-agent instruction contracts (a canonical AGENTS.md and the tool-specific bridge files — CLAUDE.md, GEMINI.md, .cursor/rules — that should import or defer to it);
agent-skill packages (skill frontmatter metadata, capability pre-approvals such as allowed-tools, bundled executable scripts or assets, and the source or marketplace provenance of third-party skills);
delegated-commerce contracts (verifiable intent mandates, payment-delegation scopes, checkout or settlement task contracts), where an agent can initiate or approve payments;
database migration contracts and persisted document formats;
retrieval chunk metadata;
SDK/API public surface;
file formats;
device or hardware protocol definitions;
A2A Agent Cards, advertised skills, authentication schemes, task-state contracts, streaming capability, push-notification capability, and registry-discovery mechanisms;
inter-agent message schemas;
subagent boundary message contracts;
callback/webhook request and response schemas;
provenance manifests for runtime/action records, content credentials, and build/source attestations;
eval dataset schemas;
policy-as-code input/output schemas.

For each contract, record: name, format, surface, location, versioning strategy, schema dialect if applicable, protocol version if applicable, protocol-object lifecycle status against the pinned protocol revision if applicable (core, extension, experimental, deprecated, or unknown), advertised capabilities, authentication/authorization scheme, producer, consumers, validation mechanism, compatibility policy, citations.

Flag:

route/action/tool without schema;
event without payload contract;
config without validation;
persisted format without versioning;
schema drift between producer and consumer;
duplicate contract names;
public SDK shape not represented as a contract;
cross-agent instruction drift: a tooling-agnostic project that ships only tool-specific instruction files with no canonical AGENTS.md, or bridge files that contradict or silently duplicate AGENTS.md instead of importing or deferring to it;
prompt arguments without schema;
MCP surface without separately recorded contract object;
A2A Agent Card or skill without auth/capability/task-state contract;
workflow description or overlay not tied to the API description it augments;
callback or push notification without request/response schema and authentication declaration;
subagent boundary without typed message contract;
retrieval chunks without typed metadata;
agent-skill package without a valid frontmatter contract;
skill capability pre-approval (allowed-tools or equivalent) or bundled executable without a matching authority declaration (route to Phase 6);
third-party skill, plugin, or extension without source or marketplace provenance;
protocol object that is deprecated or experimental at the pinned protocol revision, relied on without a recorded migration or stability position;
server-delivered UI extension without sandbox and message-boundary declaration;
payment-capable surface without a verifiable intent mandate or bounded delegation contract;
agentic output without runtime/action provenance manifest;
generated content without content-provenance position where content authenticity matters;
release/build output without build/source provenance position where supply-chain integrity matters;
claimed automation absent: governance or instruction text claiming automated enforcement that is not implemented — every "CI-enforced," "blocked at merge," or "automated by X" claim must map to an implemented gate at the claimed power class (per §9.9: a "blocked at merge" claim is satisfied only by a merge-blocking gate, not a warn-only job; route to Phase 9 for gate confirmation); claims about approval gates on authority principals stay with Phase 6's approval-not-enforced;
instruction reference broken: an instruction contract citing repository artifacts (paths, templates, checklists, configuration files) that do not resolve in the tree — environment-resolved commands are out of scope.

Boundary declarations

Do not flag a rule honestly documented as manual review as claimed-automation-absent; the flag fires only on claims of automation that no implemented gate backs.
Do not flag forward-looking statements ("will be CI-enforced") as claimed-automation-absent; roadmap language is not a claim of present enforcement.
Do not route instruction-content staleness or contradiction here — that is Phase 8 (stale-authoring-artifact, contradictory-guidance); Phase 4 flags only references that fail to resolve.
Do not equate having schemas with contract discipline unless producer, consumer, validation, and versioning are evident.
Do not require a particular schema technology.
Do not treat comments as machine-readable contracts unless the project intentionally uses comment-based IDL generation and cites it.
Do not flatten MCP or A2A into "tool exists"; their advertised surfaces carry separate contract, authority, and lifecycle implications.
Do not classify an agent-skill package as prose governance alone when it declares machine-readable metadata, capability pre-approvals, or bundled executables.
Do not treat a protocol object list remembered from training data as current; inventory objects against the pinned protocol revision and record their lifecycle status.

Outputs

audit/<date>/04-contracts.md
audit/<date>/04-contracts.json

Exit check

No unflagged ad-hoc external contract remains.
Every tool/action/skill has a schema reference or is flagged.
Every MCP or A2A surface has its protocol object inventoried separately or a missing-contract flag.
Every inventoried protocol object records a lifecycle status against the pinned protocol revision, or unknown with a search note.
Every public interface has producer and consumer evidence or an explicit consumer-unknown flag.
Every subagent boundary has a typed message contract or a flag.
Every cross-agent instruction surface resolves to a canonical AGENTS.md with consistent bridges, or carries a cross-agent-instruction-drift flag.
Every agent-skill package has a frontmatter contract and a source-provenance note recorded, or a flag.
Every enforcement claim in governance or instruction contracts maps to an implemented gate, or carries a claimed-automation-absent flag.
Every repository artifact referenced by an instruction contract resolves in the tree, or carries an instruction-reference-broken flag.

Phase 5 — State and Memory Inventory

Inputs

context map;
runtime map;
contract inventory;
profile infrastructure baseline.

Procedure

Classify every store and memory surface:

request-local-ephemeral;
session-state;
durable-conversation-state;
long-term-memory;
operator-rules-memory;
authoritative-durable;
derived-durable;
ephemeral-execution;
cache;
index;
artifact;
artifact-store;
prompt-policy-config;
session-memory;
user-memory;
tenant-memory;
agent-scratchpad;
retrieval-corpus;
retrieval-index;
eval-dataset;
audit-log;
checkpoint-state;
unknown.

These class values (here and in the §8.6 Store schema) are audit-internal taxonomy for classification, never recommended project vocabulary. Where the project bans a term (profile conventions.forbidden_terms), prose artifacts restate it in the project's canonical vocabulary while schema fields keep the taxonomy value (Prime Directive 16).

For each, record: owner context, retention, deletion or reset path, write authority, read authority, invalidation trigger, lifecycle, sensitivity classification if evident, citations.

For memory-class surfaces (operator-rules, long-term, session/user/tenant memory, agent scratchpads), additionally record the truth-maintenance path: how agent-held claims get corrected when repository facts change. This extends the invalidation trigger — the trigger records what mechanically invalidates an entry; truth maintenance records whether any discipline exists for correcting stale agent-held claims at all. Fact-responsive invalidation and bounded staleness (TTL or scheduled re-derivation) both qualify as a discipline; record which. Content staleness of authored instruction files stays with Phase 8 (stale-authoring-artifact); untested lifecycle paths stay with Phase 9 (memory-lifecycle-untested) — this target asks whether a correction path exists.

Boundary declarations

Do not multi-classify a store without explaining the split.
Do not treat caches as authoritative without evidence.
Do not merge human preferences, retrieval indexes, session messages, and agent scratchpads into one generic memory bucket.
Do not merge persistent project rules, operator memory, session state, durable conversations, retrieval corpora, and retrieval indexes into one generic memory bucket.
Do not infer retention from deployment defaults.
Do not skip retrieval corpora — they are state with retention and authority implications.

Outputs

audit/<date>/05-state.md
audit/<date>/05-state.json

Exit check

Every store has an owner or an owner-unknown flag.
Every writable store has write-authority evidence or a missing-authority flag.
Every memory surface is classified by purpose, durability, owner, and deletion/reset semantics.
Every memory-class surface records a truth-maintenance path or carries a memory-truth-maintenance-absent flag.

Phase 6 — Authority Boundaries

Inputs

runtime map;
state inventory;
contract inventory;
profile authority baseline.

Procedure

For each principal — agent, subagent, automation, tool, action, service, adapter, worker, and human approval gate — record:

readable scopes;
writable scopes;
callable tools/actions;
callable subagents;
callable external APIs;
workspace roots;
browser scope (allowed domains for browser-using agents);
filesystem scope (allowed paths for filesystem-using or computer-use agents);
secrets access;
approval policy;
approval mode and deny/ask/allow precedence where applicable;
bypass, auto-approval, or trusted-workspace modes;
protected-path behavior;
secondary credential acquisition path;
outbound network or callback scope;
callback/webhook authentication and replay protection;
hosted-versus-local execution boundary;
token delegation or exchange model;
agent identity attestation (workload identity, signed agent cards, signed-agent request headers, identity-chaining or token-exchange grants binding the agent to a user or workload);
capability pre-approvals granted by customization layers (skills, hooks, plugins) consumed by repo-operating agents, and the source-pinning or lockdown controls for those layers;
operating-agent model/CLI baseline where the profile records it (observed agent CLI versions, observed model posture, and model-alias pins with their recorded resolutions);
payment or commerce delegation (intent mandates, spending bounds, human-present versus delegated modes);
sandbox or isolation model;
escalation paths;
citations.

Identify:

capability escalation;
ambient authority;
undeclared scope;
write path without approval policy;
write path with approval policy but bypass mode enabled or unaccounted for;
deny/ask/allow precedence unclear;
approval gate present in code or comments but not connected to enforcement;
secret access broader than needed;
secondary credential path broader than the declared principal;
workspace root broader than declared task;
tool schema narrower than actual implementation authority;
computer-use or browser-use surface without sandbox declaration;
callback or push notification path without authentication model;
hosted MCP or remote-agent path without token-scope or consent boundary;
skill or customization layer that pre-approves capabilities or executes bundled scripts without an authority declaration;
customization layers consumed by repo-operating agents without source pinning, marketplace control, or vetting evidence;
model-alias pin that no longer resolves to the recorded baseline (where the profile records alias pins) — silent repointing of an alias changes the operating principal without any repo change;
review-power inversion per §9.9 (one surface with strictly greater enforcement power and strictly weaker mandated review than another — e.g., a merge-blocking surface less reviewed than a warn-only one);
payment-capable principal without a verifiable intent mandate, spending bound, or delegation contract;
server-delivered UI surface without sandbox or message-boundary declaration;
subagent without authority manifest.

Boundary declarations

Do not assume least privilege because a tool name is narrow.
Do not infer approval policy from comments unless comments are enforced by a policy layer.
Do not broaden scope to other tools when investigating one authority issue unless the phase requires a full sweep.
Do not score "approval exists" as sufficient unless bypass modes, protected paths, secondary credentials, and enforcement evidence were checked.

Outputs

audit/<date>/06-authority.md
audit/<date>/06-authority.json

Exit check

Every write-capable path has an approval policy value, even if none-required.
Every authority escalation is either explained or flagged.
Every principal has readable and writable scopes recorded.
Every browser-use, computer-use, or filesystem-use agent has a declared scope.
Every callback-capable, hosted-tool, or remote-agent principal has authentication and token-scope evidence or a missing-authority flag.
Every customization layer that grants capabilities to a repo-operating agent has authority and source-provenance evidence or a flag.
Every payment-capable or commerce-delegated principal has mandate and delegation-bound evidence or a missing-authority flag.
Where the profile records operating-agent alias pins, each pin's current resolution is confirmed against the recorded baseline or flagged model-alias-resolution-drift.
Where any review mandate exists in governance, enforcement-power and mandated-review classes are recorded for every governance-relevant surface (§9.9) — inversion detection requires classifying the unreviewed surfaces too — with inversions flagged review-power-inversion.

Phase 7 — Observability Semantics

Inputs

runtime map;
contracts;
eval baseline;
observability baseline.

Procedure

Inventory telemetry: span names, event names, metric names, metric units, log fields, trace context propagation, error attributes, model/provider attributes, token/cost/latency/quality attribution, user/tenant/workflow/tool correlation identifiers, audit logs, security events, callback/resume events, and protocol-specific events.

For agentic and model-mediated paths, verify the cost / latency / quality / provenance quartet:

Cost — token usage per span, attributable per-feature, per-tenant, per-tool, or per-workflow.
Latency — per agent loop iteration, per tool call, per subagent invocation, per model call.
Quality — eval-result correlation linkable to runtime traces; LLM-as-judge calibration scores recorded where applicable.
Provenance — tools called, retrieval sources used, model + version, prompt version, and subagent path recorded on each agentic output.

Verify semantic-convention alignment (e.g., OTel GenAI, agent, and MCP conventions where applicable) at the version pinned in §14. Record semantic-convention stability status (stable, development, experimental, deprecated, or unknown) and provider-specific extensions. Lack of conformance to stable conventions is scored separately from partial adoption of conventions still marked development or experimental.

Separate provenance into:

Runtime/action provenance — tools called, resources read, retrieval sources used, model and prompt versions, approval events, subagent path, and task/resume IDs.
Content provenance — content credentials, content-authenticity manifests, or explicit "not applicable" position for generated media/documents.
Build/source provenance — source revision, build inputs, dependency attestations, and release artifact provenance where supply-chain integrity matters.

Flag:

same event under multiple names;
same metric under incompatible units;
units conflicting with the adopted semantic convention;
missing cost/latency/quality/provenance coverage;
missing token accounting;
no trace relationship across model → tool → model loops;
eval results not linkable to runtime traces;
agentic outputs without runtime/action provenance;
generated content without content-provenance position where content authenticity matters;
build/release artifacts without build/source provenance position where supply-chain integrity matters;
semantic-convention version recorded without stability status.

Boundary declarations

Do not require a specific observability vendor.
Do not treat logging as sufficient tracing unless correlation and causality are evident.
Do not claim convention alignment without checking names, attributes, and units.
Do not credit token logging as cost attribution — attribution requires per-feature/per-tool dimensions.
Do not conflate runtime/action provenance with content credentials or build/source attestations.
Do not penalize missing development-stage semantic conventions the same way as missing stable conventions; record the distinction.

Outputs

audit/<date>/07-observability.md
audit/<date>/07-observability.json

Exit check

Naming inconsistencies are flagged.
Convention alignment is scored with citations.
Agentic paths have cost/latency/quality/provenance coverage or explicit gaps.
Semantic-convention version and stability status are recorded when conventions are claimed.

Phase 8 — Policy and Prompt / Context Separation

The unit of analysis is the assembled context: prompts plus retrieved chunks plus tool descriptions plus memory plus system instructions plus skills/SOPs. Embedded business policy can hide in any layer.

Phase 8.0 — Prompt-surface classification

Before policy analysis, classify each prompt-like surface:

runtime-production-prompt — executed by production runtime.
runtime-nonproduction-prompt — executed by dev tools, test harnesses, internal automation, or agent-runtime code that runs locally but not in shipped product.
authoring-artifact-prompt — template, example, or snippet used by humans while authoring or directing agents; not executed by product runtime.
documentation-about-prompts — explanatory material, not itself a prompt.
skill-or-sop — files like SKILL.md, AGENTS.md, CLAUDE.md acting as standing instructions for agents.
server-exposed-prompt — protocol-advertised prompt exposed by an MCP-like server or remote agent.
not-a-prompt — false positive.

Each class receives a different treatment in Phase 8.1.

For projects with no runtime LLM surface, Phase 8 still executes — against the runtime non-production, authoring artifact, and skill-or-sop classes — and produces non-vacuous findings. Phase 8 is never silently skipped.

Phase 8.1 — Policy separation treatment

Runtime production prompts are checked for embedded product policy, authority policy, compliance rules, thresholds, roles, rates, and undeclared tool behavior.
Runtime non-production prompts are checked for policy that can affect generated code, infrastructure, governance, or release artifacts.
Authoring-artifact prompts are checked for drift from current code, docs, ADRs, operator conventions, and safety boundaries.
Documentation about prompts is checked only for contradictory guidance that could mislead future agents or developers.
Skill/SOP files are checked for embedded policy and for convention-vs-policy confusion (rules expressed here may belong in code).
Server-exposed prompts are checked as both contracts and privileged prompt surfaces: verify parameters, caller eligibility, injection boundaries, and whether untrusted inputs can enter developer/system or other privileged context.

Additionally check:

Retrieval-augmented surfaces — locate retrieval policy (what's retrieved, what's filtered, what's reranked). Check whether retrieval policy encodes business rules that belong in domain code.
Tool descriptions — check whether descriptions encode policy ("only invoke this if amount > $10,000") that belongs in the tool's call site.
Untrusted input boundaries — identify whether user, tool, retrieval, resource, or remote-agent content can enter developer/system messages, privileged prompt context, policy context, or tool descriptions without structured boundary controls.
Server-delivered UI surfaces — where a protocol extension renders server-provided UI (sandboxed app or iframe resources), verify the sandbox declaration, the message-channel boundary, and whether UI-originated input can enter privileged context (route to Phases 4 and 6).

Prompt and context values to grep and classify include:

currency amounts;
numeric thresholds;
role names;
time windows;
quotas;
rates;
jurisdiction or compliance assertions;
approval rules;
authority grants;
secrets-handling instructions;
tool-use constraints;
test or release pass/fail criteria;
eval rubrics that gate behavior.

Locate policy artifacts: domain policy code, declarative policy files, configuration, ADRs, decision ledgers, governance rules, access-control rules, feature flags, schema constraints, eval rubrics.

Classify each prompt or context surface:

pure-instruction;
instruction-with-parameters;
embedded-policy;
policy-masquerade;
retrieval-policy-leak;
tool-description-policy-leak;
server-prompt-policy-leak;
privileged-context-injection-risk;
stale-authoring-artifact;
contradictory-guidance;
unclassified.

Boundary declarations

Do not mark a non-runtime prompt as vacuously safe.
Do not classify authoring artifacts using only runtime-prompt criteria.
Do not recommend policy extraction unless a plausible policy home exists or the finding states that no policy home exists.
Do not treat templated variables as safe unless the variable source is policy-controlled.
Do not skip retrieval pipelines because they "aren't prompts."
Do not treat server-exposed prompts as ordinary docs; they are callable prompt contracts plus runtime context surfaces.

Outputs

audit/<date>/08-policy.md
audit/<date>/08-policy.json
audit/<date>/08-prompt-surfaces.json

Exit check

Every prompt-like surface is classified by surface type.
Every embedded-policy finding cites exact lines and the missing or conflicting policy home.
Every stale authoring artifact cites the current source it contradicts or states that no source exists.
Every server-exposed prompt, server-delivered UI surface, and privileged-context input path is mapped to Phase 4 and Phase 6 or explicitly marked not applicable.

Phase 9 — Evals and Quality Gates

Inputs

agent runtime map;
contracts;
prompts;
tools/actions;
retrieval surfaces;
subagent boundaries;
protocol surfaces;
async/background lifecycle surfaces;
observability baseline.

Procedure

Locate eval suites, golden datasets, regression fixtures, regression-trap corpora, human-review rubrics, automated scorers, model or prompt comparison records, CI quality gates, release gates, drift tracking, protocol-conformance tests, approval-path tests, async/resume lifecycle tests, safety/security test suites, hardware/sensor/external-system verification suites where relevant.

Classify eval mode for each suite:

offline — golden-data regression. Run pre-merge and on schedule.
online — production sampling with LLM-as-judge or classifier scoring. Run continuously.
live — canary deployments, A/B comparison, shadow mode.
calibration — scoring-method validation (does the LLM judge agree with humans?).
regression-trap — behavioral traps seeded from observed agent failures, replayed to catch recurrence. Distinct from offline golden-data regression (which scores expected outputs) and from code regression tests: each trap encodes a previously observed failure and cites the incident that motivated it. A suite seeded from past failures but scored as golden expected outputs may satisfy both descriptions — classify it regression-trap only when each case cites its motivating incident; otherwise offline.

Map each suite to: agent/tool/action/prompt/retrieval-surface/subagent/protocol-surface/lifecycle path under test, pass criteria, scoring method, current pass rate, dataset version, CI integration, release gate status, drift tracking, ownership, citations.

Flag:

model-mediated or agent-mediated path without eval coverage;
tool/action with write authority but no safety test;
prompt without regression fixture;
eval without golden or reference data;
eval not run in CI;
eval in CI but not at release gate;
evaluator not versioned;
LLM-as-judge surface without calibration data;
quality result not linked to observability;
high-risk behavior requiring only manual review with no rubric;
retrieval surface uncovered;
subagent surface uncovered;
protocol-advertised tool/resource/prompt/skill/task surface uncovered;
approval or bypass path untested;
background, paused, resumable, durable, or callback lifecycle untested;
memory retention or deletion path untested where persistence is material;
eval suite or scoring dependency hosted on a platform that is deprecated or scheduled for shutdown.

Boundary declarations

Do not require LLM judges; classify the scoring method actually used.
Do not treat unit tests as evals unless they test behavior quality against expected outputs or rubrics.
Do not assume no eval is required; require an operator or artifact justification.
Do not credit a single passing eval as coverage.
Do not credit a trap corpus with no runnable harness as coverage; per the Phase 10.5 rule it demotes to manual-review-only — it is documentation until harnessed.
Do not treat protocol schema validation as behavior coverage unless the behavior, lifecycle, and authority paths are tested too.

Outputs

audit/<date>/09-evals.md
audit/<date>/09-evals.json

Exit check

Every model-mediated or agent-mediated entrypoint maps to an eval suite or a cited no-eval-required justification.
Every write-capable tool/action has some quality, safety, or policy gate identified or flagged.
Every protocol-advertised remote capability and async/resume path has conformance or lifecycle coverage identified or flagged.
CI and release-gate integration status are recorded separately.

Phase 10 — Findings, Scoring, and Fitness Functions

Inputs

phase artifacts 0–9;
routed audit-attention flags;
strategic themes;
known debt;
prior audit results, if any.

Procedure

Score each dimension using the rubric in §11.
Produce structural current-state findings only (10-findings.*).
Produce future-state fitness-function candidates separately (10-fitness-functions.*).
Cross-reference findings and fitness functions without sharing IDs (findings use F-NNN, fitness functions use FF-NNN); ids follow the per-cycle durability discipline in §10.2.
Rank findings by priority.
Apply strategic-theme weighting where applicable.
Classify caveats per §9.6.
For each implemented fitness function with non-trivial matching logic, record whether it ships a negative self-test wired to run wherever the fitness function runs; absence reduces the credit it earns under §11.11.

10.1 Finding priority

priority = severity × confidence × strategic_weight × reversibility_factor

Where:

severity — 1–5.
confidence — 0.25–1.0 based on evidence strength.
strategic_weight — 1.0 unless an operator-defined theme applies (default 1.5× for direct relevance, 1.2× for indirect; operator may override).
reversibility_factor — higher when delaying remediation makes later correction harder.

Do not hide low-severity findings if they are strategically relevant.

10.2 Finding vs. fitness function separation

A finding describes a present structural state: current drift, missing contract, ambiguous authority, mixed policy location, unsupported claim, absent eval, telemetry mismatch, missing provenance.

A fitness function describes a future safeguard: static rule, schema diff, contract registry check, dependency boundary check, prompt scan, authority manifest check, telemetry semantic linter, eval coverage check, ADR template validation, release gate.

A finding may reference one or more fitness functions. A fitness function may protect against one or more findings. IDs remain independent.

Ids are also per-cycle: each audit cycle starts its own F-NNN/FF-NNN namespace. The cycle records its id discipline — either ids are monotonic and never reused across cycles, or any id cited in an artifact that outlives its cycle (READMEs, configuration, instruction files, commit messages) is cycle-qualified with a YYYY-MM-DD/ prefix. Artifacts that carry their own cycle date (the audit/<date>/ outputs, dated changelog entries) keep bare ids for that cycle's own ids; an id cited from a different cycle is qualified even there. Either discipline satisfies this rule; the choice is recorded once in the project's conventions or governance record, noted in each cycle's 00-scope.md, and kept. The in-run id fields keep the §8.11/§8.12 anchored patterns — qualification applies to ids as cited, with the optional cycle field carrying the qualifier in structured outputs.

Boundary declarations

Do not combine a structural finding and a future safeguard into one ID.
Do not score by severity alone when a strategic theme exists.
Do not propose a fitness function without naming the enforceable rule and enforcement category.
Do not write SUMMARY.md before Phase 10.5 smoke-test.
Do not propose a fitness function whose enforcement tech does not exist for the project's stack.
Do not cite a per-cycle id bare in an artifact that outlives its cycle unless the recorded discipline is monotonic-never-reused.
Do not propose an implemented fitness function with non-trivial matching logic without stating whether a negative self-test ships with it.

Outputs

audit/<date>/10-findings.md
audit/<date>/10-findings.json
audit/<date>/10-scores.json
audit/<date>/10-fitness-functions.md
audit/<date>/10-fitness-functions.json

Exit check

Every score cites evidence from phase artifacts.
Every finding has source evidence and a confidence level.
Every fitness function names enforcement category, scope, failure condition, and owner recommendation.
Findings and fitness functions have separate IDs.
The cycle's id discipline is recorded, and ids cited outside dated cycle artifacts follow it.
Every implemented fitness function with non-trivial matching logic records negative-self-test presence or absence.

Phase 10.5 — Finding Smoke-Test

This phase exists because audit cycles repeatedly shipped findings whose evidence had drifted between profile snapshot and audit execution, then drifted further between audit shipping and remediation. Smoke-test cost is low; rework cost in remediation is high.

Inputs

draft findings;
current working branch;
profile snapshot evidence;
phase artifacts.

Procedure

For each current-state finding:

Re-read or re-grep the cited evidence against the current working branch (HEAD). Where a citation records an evidence_lane (§8.1), re-verify through that lane; a citation whose lane is unreachable from the current session (always true of unavailable) records not-run with the lane as the reason.
Record the current result.
Compare with the snapshot-backed finding.
Classify smoke-test outcome:
- confirmed-current — evidence still supports the finding at the cited location with cited semantics.
- re-evidenced — substance still true; citations updated (e.g., line numbers shifted, file renamed).
- reclassified — finding substance changes; severity or category changes.
- promoted — current evidence shows a broader or more serious issue than originally captured.
- demoted — current evidence weakens the issue but does not remove it.
- struck — finding no longer supported; retained in the smoke-test log for audit-trail.
- drift-only — discrepancy between snapshot and current is itself the finding.
- not-run — smoke-test could not be performed (cite reason).
Update findings and the smoke-test log.

For each fitness-function candidate:

Verify the proposed enforcement tech is currently installed or installable in the project's CI.
If a fitness function would be unenforceable, demote to manual-review-only.

Boundary declarations

Do not erase the original snapshot evidence.
Do not silently update line numbers without recording that re-evidencing occurred.
Do not convert a failed smoke-test into a remediation claim.
Do not use smoke-test to expand scope beyond the finding unless the outcome is explicitly promoted (operator notice required).
Do not re-derive a finding from scratch; smoke-test verifies, it does not investigate.

Outputs

audit/<date>/10.5-finding-smoke-test.md
audit/<date>/10.5-finding-smoke-test.json
updated 10-findings.*

Exit check

Every finding has a smoke-test outcome.
Every struck finding is absent from final priority ranking but retained in the smoke-test log.
Every drift-only item is recorded as profile/code drift.

If more than one third of findings receive struck or drift-only outcomes, halt per §4.1 and request a fresh profile snapshot.

Phase 11 — Summary and Cycle-History Notes

Inputs

all phase artifacts;
smoke-tested findings;
fitness functions;
halted/resumed state if any.

Procedure

Write SUMMARY.md last.
Produce a one-page operator entry point with: audit mode, profile snapshot date, score table, top findings by priority, active strategic themes and their effects, profile/current-branch drift summary, proposed fitness functions, caveats and halt/resume history, recommended next audit cadence, pointer to detailed phase artifacts.
Write cycle-history-notes.md containing conventions or process patterns discovered during the audit that the operator should consider adopting into profile/cycle-history.md on the next profile run.

Role separation: The audit proposes additions to cycle history. The profile directive commits them, after operator approval. The audit must not edit profile/cycle-history.md directly.

Boundary declarations

Do not summarize findings that were struck in Phase 10.5 as active findings.
Do not hide caveats or halt history.
Do not add new findings in the summary.
Do not edit profile/cycle-history.md directly.

Outputs

audit/<date>/SUMMARY.md
audit/<date>/cycle-history-notes.md

Exit check

Summary references final smoke-tested findings only.
Operator can trace every top finding to source evidence.
Cycle-history notes are suggestions, not automatically adopted conventions.

8. Output Schemas

The audit produces fully valid JSON. Fragments below define the required shape. A project may add fields but must not remove required fields.

8.1 Citation

{
  "type": "object",
  "required": ["path", "lines", "evidence", "method"],
  "properties": {
    "path": {"type": "string"},
    "lines": {"type": "string"},
    "evidence": {"type": "string"},
    "method": {"type": "string", "description": "command or read operation that produced this evidence (e.g., 'rg', 'ast-grep', 'view')"},
    "snapshot_ref": {"type": "string", "description": "git revision or profile date the evidence was captured against"},
    "current_ref": {"type": "string", "description": "git revision the evidence was re-validated against in Phase 10.5"},
    "observed_at": {"type": "string", "description": "when the evidence was captured (ISO-8601); snapshot_ref/current_ref identify WHICH revision, observed_at records WHEN"},
    "valid_until": {"type": "string", "description": "forward-looking trust horizon for steady-state/focused-diff consumers (ISO-8601); past it, re-verify before relying on this citation"},
    "evidence_lane": {"enum": ["repo-local", "host-verifiable", "unavailable"], "description": "channel through which this evidence can be re-verified: repo-local (from the working tree), host-verifiable (only via the hosting platform's interface — e.g., branch-protection settings or check rollups), unavailable (no re-verification channel exists beyond the original observation). The lane is intrinsic to the evidence, not to the session: Phase 10.5 records not-run for any citation whose lane is unreachable from the current session. A re-verification lane, not a §9.8 provenance class"}
  }
}

8.2 VocabularyTerm

{
  "type": "object",
  "required": ["term", "definitions", "collision"],
  "properties": {
    "term": {"type": "string"},
    "definitions": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["unit", "definition", "citations"],
        "properties": {
          "unit": {"type": "string"},
          "definition": {"type": "string"},
          "context_hint": {"type": "string"},
          "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
        }
      }
    },
    "collision": {"type": "boolean"},
    "collision_type": {"enum": ["same-term-different-meaning", "different-term-same-meaning", "audit-taxonomy-collision", "none"]}
  }
}

8.3 BoundedContext

{
  "type": "object",
  "required": [
    "name", "status", "owner", "ubiquitous_language", "authority_basis",
    "inbound_commands", "outbound_events", "external_dependencies", "citations"
  ],
  "properties": {
    "name": {"type": "string"},
    "status": {"enum": ["confirmed", "candidate", "claimed-only", "rejected", "merged", "split"]},
    "merge_target": {"type": "string"},
    "split_into": {"type": "array", "items": {"type": "string"}},
    "owner": {"type": "string"},
    "ubiquitous_language": {"type": "array", "items": {"type": "string"}},
    "authority_basis": {
      "type": "array",
      "items": {"enum": ["authoritative-store", "event-source", "external-authority", "stateless-policy", "unknown"]}
    },
    "authoritative_stores": {"type": "array", "items": {"type": "string"}},
    "inbound_commands": {"type": "array", "items": {"type": "string"}},
    "outbound_events": {"type": "array", "items": {"type": "string"}},
    "external_dependencies": {"type": "array", "items": {"type": "string"}},
    "produced_contracts": {"type": "array", "items": {"type": "string"}},
    "consumed_contracts": {"type": "array", "items": {"type": "string"}},
    "subagents_consumed": {"type": "array", "items": {"type": "string"}},
    "subagents_exposed": {"type": "array", "items": {"type": "string"}},
    "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
  }
}

8.4 Entrypoint

{
  "type": "object",
  "required": ["id", "kind", "path", "sync_model", "side_effects", "touches_loop", "citations"],
  "properties": {
    "id": {"type": "string"},
    "kind": {"enum": ["http-route", "rpc", "queue-consumer", "cron", "cli", "ui-action", "agent-loop", "subagent-call", "remote-agent-call", "tool", "resource", "resource-template", "root", "sampling", "elicitation", "completion", "task", "prompt", "webhook", "callback", "sdk-call", "batch", "device", "durable-workflow", "background-trigger", "a2a-receiver", "agent-card-discovery", "other"]},
    "path": {"type": "string"},
    "sync_model": {"enum": ["sync", "async", "streaming", "long-running", "scheduled", "batch", "background", "paused-for-approval", "resumable", "durable", "event-triggered", "unknown"]},
    "execution_mode": {"enum": ["sync", "streaming", "background", "paused", "resumable", "durable-workflow", "scheduled", "batch", "event-triggered", "unknown"]},
    "side_effects": {"type": "array"},
    "touches_loop": {"type": "boolean"},
    "termination_condition": {"type": "string"},
    "lifecycle_contract": {"type": "string"},
    "resume_state": {"type": "string"},
    "callback_channel": {"type": "string"},
    "approval_gates": {"type": "array"},
    "checkpoint_state": {"type": "string"},
    "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
  }
}

8.5 Contract

{
  "type": "object",
  "required": ["name", "format", "surface", "location", "versioning", "producers", "consumers", "citations"],
  "properties": {
    "name": {"type": "string"},
    "format": {"enum": ["openapi", "arazzo", "overlay", "json-schema", "protobuf", "graphql", "idl", "zod", "pydantic", "typescript", "kotlin", "go-type", "python-type", "rust-type", "mcp-manifest", "a2a-agent-card", "workflow-description", "agent-skill-package", "provenance-attestation", "ad-hoc", "other"]},
    "surface": {"enum": ["http", "rpc", "event", "workflow", "tool", "resource", "resource-template", "root", "sampling", "elicitation", "completion", "task", "extension", "ui-app", "registry-discovery", "prompt", "config", "persisted-format", "retrieval-metadata", "sdk", "file", "device", "policy", "a2a", "agent-card", "skill", "task-state", "subagent", "agent-skill", "commerce", "callback", "provenance-runtime-action", "provenance-content", "provenance-build-source", "cross-agent-instruction", "other"]},
    "location": {"type": "string"},
    "versioning": {"enum": ["semver", "hash", "date", "schema-version", "none", "unknown"]},
    "schema_dialect": {"type": "string"},
    "protocol_version": {"type": "string"},
    "protocol_object_status": {"enum": ["core", "extension", "experimental", "deprecated", "not-protocol-object", "unknown"], "description": "lifecycle status of this object at the protocol revision pinned in Phase 0 (§14)"},
    "advertised_capabilities": {"type": "array", "items": {"type": "string"}},
    "auth_scheme": {"type": "string"},
    "producers": {"type": "array", "items": {"type": "string"}},
    "consumers": {"type": "array", "items": {"type": "string"}},
    "validation": {"type": "string"},
    "compatibility_policy": {"type": "string"},
    "flags": {"type": "array", "items": {"enum": ["route-without-spec", "tool-without-schema", "event-without-payload", "config-without-validation", "version-drift", "duplicate-name", "producer-consumer-drift", "sdk-surface-uncontracted", "prompt-args-without-schema", "mcp-surface-uninventoried", "a2a-card-without-auth", "a2a-task-contract-missing", "workflow-overlay-unlinked", "callback-schema-missing", "subagent-boundary-untyped", "retrieval-chunk-untyped", "skill-frontmatter-invalid", "skill-authority-undeclared", "skill-provenance-unvetted", "protocol-object-deprecated", "ui-extension-unsandboxed", "commerce-mandate-missing", "runtime-provenance-missing", "content-provenance-position-missing", "build-provenance-position-missing", "cross-agent-instruction-drift", "claimed-automation-absent", "instruction-reference-broken", "provenance-missing"]}},
    "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
  }
}

8.6 Store

{
  "type": "object",
  "required": ["name", "classification", "owner_context", "retention", "write_authority", "citations"],
  "properties": {
    "name": {"type": "string"},
    "classification": {"enum": ["request-local-ephemeral", "session-state", "durable-conversation-state", "long-term-memory", "operator-rules-memory", "authoritative-durable", "derived-durable", "ephemeral-execution", "cache", "index", "artifact", "artifact-store", "prompt-policy-config", "session-memory", "user-memory", "tenant-memory", "agent-scratchpad", "retrieval-corpus", "retrieval-index", "eval-dataset", "audit-log", "checkpoint-state", "unknown"]},
    "owner_context": {"type": "string"},
    "retention": {"type": "string"},
    "read_authority": {"type": "array", "items": {"type": "string"}},
    "write_authority": {"type": "array", "items": {"type": "string"}},
    "invalidation_trigger": {"type": "string"},
    "truth_maintenance": {"type": "string", "description": "how agent-held claims in this store get corrected when repository facts change; extends invalidation_trigger (the mechanical trigger) with the correction discipline"},
    "deletion_or_reset_path": {"type": "string"},
    "lifecycle": {"type": "string"},
    "sensitivity": {"type": "string"},
    "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
  }
}

8.7 Authority

{
  "type": "object",
  "required": ["principal", "readable_scopes", "writable_scopes", "callable_capabilities", "approval_policy", "citations"],
  "properties": {
    "principal": {"type": "string"},
    "readable_scopes": {"type": "array", "items": {"type": "string"}},
    "writable_scopes": {"type": "array", "items": {"type": "string"}},
    "callable_capabilities": {"type": "array", "items": {"type": "string"}},
    "callable_subagents": {"type": "array", "items": {"type": "string"}},
    "callable_externals": {"type": "array", "items": {"type": "string"}},
    "workspace_roots": {"type": "array", "items": {"type": "string"}},
    "browser_scope": {"type": "array", "items": {"type": "string"}},
    "filesystem_scope": {"type": "array", "items": {"type": "string"}},
    "secrets_access": {"type": "array", "items": {"type": "string"}},
    "approval_policy": {"type": "string"},
    "approval_mode": {"enum": ["deny", "ask", "allow", "auto-approved", "human-in-loop", "blocked", "none-required", "unknown"]},
    "approval_precedence": {"type": "string"},
    "bypass_modes": {"type": "array", "items": {"type": "string"}},
    "protected_paths": {"type": "array", "items": {"type": "string"}},
    "secondary_credentials": {"type": "array", "items": {"type": "string"}},
    "outbound_network_scope": {"type": "array", "items": {"type": "string"}},
    "callback_auth": {"type": "string"},
    "hosted_or_local": {"enum": ["hosted", "local", "hybrid", "n/a", "unknown"]},
    "token_delegation": {"type": "string"},
    "sandbox_model": {"type": "string"},
    "flags": {"type": "array", "items": {"enum": ["escalation", "ambient-authority", "undeclared-scope", "write-without-approval-policy", "approval-not-enforced", "bypass-mode-unaccounted", "approval-precedence-unclear", "secret-scope-too-broad", "secondary-credential-too-broad", "workspace-root-too-broad", "callback-auth-missing", "remote-agent-token-scope-unknown", "computer-use-unsandboxed", "skill-authority-undeclared", "customization-source-unpinned", "ui-extension-unsandboxed", "commerce-delegation-unbounded", "model-alias-resolution-drift", "review-power-inversion", "subagent-without-policy"]}},
    "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
  }
}

8.8 TelemetrySignal

{
  "type": "object",
  "required": ["name", "kind", "producers", "attributes", "citations"],
  "properties": {
    "name": {"type": "string"},
    "kind": {"enum": ["span", "event", "metric", "log", "audit-log", "eval-result"]},
    "producers": {"type": "array", "items": {"type": "string"}},
    "attributes": {"type": "array", "items": {"type": "string"}},
    "unit": {"type": "string"},
    "semantic_convention": {"type": "string"},
    "semantic_convention_version": {"type": "string"},
    "semantic_convention_stability": {"enum": ["stable", "development", "experimental", "deprecated", "unknown"]},
    "provider_extensions": {"type": "array", "items": {"type": "string"}},
    "genai_aligned": {"type": "boolean"},
    "carries_provenance": {"type": "boolean"},
    "provenance_kinds": {"type": "array", "items": {"enum": ["runtime-action", "content", "build-source", "unknown"]}},
    "cost_latency_quality_provenance": {
      "type": "object",
      "properties": {
        "cost": {"type": "boolean"},
        "latency": {"type": "boolean"},
        "quality": {"type": "boolean"},
        "provenance": {"type": "boolean"}
      }
    },
    "flags": {"type": "array", "items": {"enum": ["naming-inconsistent", "attribute-missing", "unit-mismatch", "semantic-stability-unpinned", "no-token-accounting", "no-cost-attribution", "no-quality-attribution", "no-runtime-action-provenance", "no-content-provenance-position", "no-build-source-provenance-position", "no-provenance", "trace-break", "no-eval-correlation"]}},
    "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
  }
}

8.9 PromptSurface

{
  "type": "object",
  "required": ["id", "path", "surface_type", "classification", "citations"],
  "properties": {
    "id": {"type": "string"},
    "path": {"type": "string"},
    "surface_type": {"enum": ["runtime-production-prompt", "runtime-nonproduction-prompt", "authoring-artifact-prompt", "documentation-about-prompts", "skill-or-sop", "server-exposed-prompt", "not-a-prompt"]},
    "classification": {"enum": ["pure-instruction", "instruction-with-parameters", "embedded-policy", "policy-masquerade", "retrieval-policy-leak", "tool-description-policy-leak", "server-prompt-policy-leak", "privileged-context-injection-risk", "stale-authoring-artifact", "contradictory-guidance", "unclassified"]},
    "embedded_values": {"type": "array", "items": {"type": "object", "required": ["value", "kind", "line"], "properties": {"value": {"type": "string"}, "kind": {"enum": ["currency", "threshold", "role", "duration", "quota", "rate", "jurisdiction", "approval", "authority", "secret", "tool-constraint", "release-criterion", "eval-rubric"]}, "line": {"type": "integer"}}}},
    "policy_home": {"type": "string"},
    "drift_target": {"type": "string"},
    "privileged_context": {"type": "boolean"},
    "untrusted_input_boundary": {"type": "string"},
    "server_exposed": {"type": "boolean"},
    "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
  }
}

8.10 EvalSuite

{
  "type": "object",
  "required": ["name", "covers", "scoring_method", "mode", "ci_integrated", "citations"],
  "properties": {
    "name": {"type": "string"},
    "mode": {"enum": ["offline", "online", "live", "calibration", "regression-trap"]},
    "covers": {"type": "array", "items": {"type": "string"}},
    "golden_dataset_path": {"type": "string"},
    "dataset_version": {"type": "string"},
    "scoring_method": {"enum": ["exact-match", "rubric", "llm-judge", "classifier", "statistical", "human-review", "simulation", "hardware-verification", "reference-free", "custom", "unknown"]},
    "current_pass_rate": {"type": "number"},
    "ci_integrated": {"type": "boolean"},
    "release_gate": {"type": "boolean"},
    "drift_tracking": {"type": "boolean"},
    "judge_calibrated": {"type": "boolean"},
    "owner": {"type": "string"},
    "flags": {"type": "array", "items": {"enum": ["no-golden-data", "no-ci", "no-release-gate", "regression-silenced", "model-path-uncovered", "write-tool-untested", "prompt-untested", "unversioned-evaluator", "judge-uncalibrated", "retrieval-surface-uncovered", "subagent-surface-uncovered", "protocol-surface-uncovered", "approval-path-untested", "async-lifecycle-untested", "memory-lifecycle-untested", "eval-platform-deprecated"]}},
    "citations": {"type": "array", "items": {"$ref": "#/$defs/Citation"}}
  }
}

8.11 Finding

{
  "type": "object",
  "required": ["id", "title", "dimension", "severity", "confidence", "status", "snapshot_evidence", "smoke_test", "recommendation_boundary"],
  "properties": {
    "id": {"type": "string", "pattern": "^F-[0-9]{3}$"},
    "cycle": {"type": "string", "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$", "description": "audit-cycle date qualifying this id across cycles (optional; see the §10.2 id discipline)"},
    "title": {"type": "string"},
    "dimension": {"type": "string"},
    "severity": {"type": "integer", "minimum": 1, "maximum": 5},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "status": {"enum": ["active", "struck", "drift-only", "superseded"]},
    "strategic_relevance": {"enum": ["direct", "indirect", "none"]},
    "finding_bucket": {"type": "string"},
    "snapshot_evidence": {"type": "array", "items": {"$ref": "#/$defs/Citation"}},
    "current_evidence": {"type": "array", "items": {"$ref": "#/$defs/Citation"}},
    "smoke_test": {"enum": ["confirmed-current", "re-evidenced", "reclassified", "promoted", "demoted", "struck", "drift-only", "not-run"]},
    "related_fitness_functions": {"type": "array", "items": {"type": "string"}},
    "recommendation_boundary": {"type": "string"}
  }
}

8.12 FitnessFunction

{
  "type": "object",
  "required": ["id", "title", "rule", "enforcement_category", "scope", "failure_condition", "ff_bucket"],
  "properties": {
    "id": {"type": "string", "pattern": "^FF-[0-9]{3}$"},
    "cycle": {"type": "string", "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$", "description": "audit-cycle date qualifying this id across cycles (optional; see the §10.2 id discipline)"},
    "title": {"type": "string"},
    "rule": {"type": "string"},
    "enforcement_category": {"enum": ["dependency-boundary", "schema-diff", "contract-registry", "protocol-contract-registry", "static-analysis", "policy-as-code", "prompt-scan", "authority-manifest", "approval-matrix", "memory-lifecycle-lint", "telemetry-lint", "provenance-attestation", "eval-coverage", "adr-template", "release-gate", "companion-doc-drift", "manual-review-only", "custom"]},
    "scope": {"type": "string"},
    "failure_condition": {"type": "string"},
    "ff_bucket": {"type": "string"},
    "related_findings": {"type": "array", "items": {"type": "string"}},
    "negative_self_test": {"type": "string", "description": "where this fitness function's negative self-test lives and how it runs; record 'absent' when an implemented function with non-trivial matching logic ships none (reduces §11.11 credit)"},
    "implementation_notes": {"type": "string"}
  }
}

finding_bucket and ff_bucket are independent classifications. A single audit observation may produce one entry in each list with different bucket assignments — the schema makes this orthogonality explicit.

9. Decision Matrices

9.1 Tool vs. Resource vs. Prompt vs. Workflow

Trait	Classification
Performs computation or causes side effects	`tool` or `action`
Read-only, addressable, returns content without side effects	`resource`
Parameterized read-only addressable content in a protocol that supports templates	`resource-template` plus contract check
Reusable instruction template consumed by a model or agent	`prompt`
Parameterized read-only computation	`tool` unless the protocol explicitly supports parameterized resources
Static metadata with no parameters	`resource`
Declares allowed filesystem/workspace exposure to a protocol client	`root` plus authority check
Requests model assistance from a client or host	`sampling` plus authority and privacy check
Requests additional user input through a protocol flow	`elicitation` plus UX and authority check
Accepts user/business state and creates model-directed instructions	`prompt` plus policy check
Multi-step sequence with durable state, approvals, or retries	`workflow` or `application` path, not only a tool
Tool that delegates to model calls	`agent-runtime` plus `tool` surface
Advertises a remote agent's identity, skills, auth, and capabilities	`agent-card` contract plus authority check
Represents remote-agent task states, push notifications, or streaming lifecycle	`task-state` or `callback` contract plus runtime check
Durable or async request lifecycle advertised by a protocol surface	`task` contract plus lifecycle check
Server-delivered interactive UI (sandboxed app or iframe resource)	`ui-app` contract plus sandbox and injection check
Skill package with frontmatter metadata, capability pre-approvals, or bundled executables	`agent-skill` contract plus authority and provenance check

Flag mismatches.

9.2 Agent or automation split justification

Signal	Score
Prompt/instruction set has more than five conditional branches	+1
Capabilities span more than two authority zones	+1
Eval suites differ in failure modes	+1
Model/runtime requirements differ materially (vision vs. reasoning vs. fast vs. on-device)	+1
Memory scopes differ: user, tenant, session, workspace, tool	+1
Workflow has independently failing long-running stages	+1
Tools/actions overlap semantically and confuse selection	+1
Safety or approval policy differs by capability	+1
Context window pressure causes frequent truncation	+1
Subagent invocation would cross a regulatory or trust boundary	+1

0–1: likely single-agent or single-runtime path is sufficient.
2: inspect for clarity but do not recommend split solely on score.
3 or more: split or explicit orchestration boundary is justified if supported by evidence.

When split, every subagent boundary requires a typed message contract (Phase 4) and an authority declaration (Phase 6).

9.3 Sync vs. async vs. durable boundary

Trait	Boundary
User waits and P95 is comfortably under interaction timeout	`sync`
User waits and output can be incremental	`streaming`
Work exceeds typical request timeout	`async` or `long-running`
User does not need immediate result	`async`, `scheduled`, or `batch`
Work continues after user-visible response or after the initiating session ends	`background`; lifecycle and provenance required
Work stops awaiting explicit human approval or additional user input	`paused-for-approval`; approval state and timeout required
Work can be resumed after interruption, host restart, or callback completion	`resumable`; resume token/state contract required
Tool calls an agent or automation that can call more tools	`long-running`; termination condition required
External device, human approval, or external queue controls completion	`long-running` or `async`; lifecycle contract required
State must survive process restart, retry, or migration	`durable`; checkpoint state required
External event or registry discovery starts the path	`event-triggered`; trigger contract required

9.4 Embedded policy in prompts and contexts

A value or instruction inside prompt text, retrieval filter logic, tool description, system instruction, or skill/SOP file is embedded policy when any of the following are true:

It represents a business, compliance, release, authority, pricing, safety, eligibility, or approval rule.
Changing it would change externally visible behavior.
It appears only in prompt or context surfaces and not in policy, domain code, configuration, ADRs, or eval rubrics.
It controls tool choice, write authority, data visibility, or human approval.
It defines pass/fail criteria for generated artifacts or release decisions.

Recommendation template: extract or reference the rule from a policy-controlled location; pass only the current value or decision result into the prompt; add a test or fitness function that prevents prompt-only policy drift.

9.5 Strategic relevance

Value	Meaning	Default weight
`direct`	Finding materially affects an operator-stated strategic theme.	1.5×
`indirect`	Finding affects a dependency or precondition of a strategic theme.	1.2×
`none`	Finding is structurally relevant but not tied to any strategic theme.	1.0×

The agent must cite why direct or indirect applies. If no strategic theme exists, all findings are none.

9.6 Caveat classification

Caveat type	Treatment
`substantive-deviation`	Requires operator awareness and may require rescope or remediation change.
`cosmetic-or-framing-deviation`	Record for awareness; does not block if substance matches.
`exact-match`	No caveat needed unless explicitly requested by operator.

Agents are expected to flag deviations. Honest caveats are signal, not noise.

9.7 Authority matrix completeness

Authority facet	Required evidence
Read scope	paths, resources, records, tenants, domains, or APIs the principal can read
Write scope	paths, records, tools, APIs, devices, or external systems the principal can mutate
Callable capabilities	tools, actions, subagents, workflows, resources, prompts, or remote agents callable by the principal
Approval mode	`deny`, `ask`, `allow`, `auto-approved`, `human-in-loop`, `blocked`, `none-required`, or `unknown`
Precedence	whether deny overrides ask/allow, project rules override user rules, or protected paths override broad permissions
Bypass modes	any trusted workspace, auto-approve, emergency, CI, test, admin, or hook-bypass behavior
Credentials	direct secrets, delegated tokens, secondary credential flows, OAuth scopes, or host-managed credentials
Network/callback scope	outbound domains, webhook receivers, push notifications, replay protection, and callback authentication
Agent identity	workload identity, signed agent identity (signed agent cards, signed request headers), identity-chaining or token-exchange grants binding the agent to a user or workload
Delegated commerce	verifiable intent mandates, spending bounds, human-present versus delegated modes, settlement identity binding (only where an agent can initiate or approve payments)
Isolation	sandbox roots, browser/computer-use restrictions, hosted-vs-local boundary, filesystem scope
Audit trail	where approval, denial, bypass, credential use, and side effects are recorded

A principal is not "scoped" merely because some of these fields are documented. Scoring requires enforcement evidence or an explicit gap.

9.8 Provenance split

Provenance class	Evidence target
`runtime-action`	model, prompt version, tools/resources called, retrieved sources, approvals, subagent path, task/resume IDs, output artifact ID
`content`	content credentials, media/document generation manifest, authenticity assertion, or explicit not-applicable position
`build-source`	source revision, build inputs, dependency attestations, generated artifact hash, release/signing record

Do not use one class as evidence for another unless an artifact explicitly links them.

9.9 Review-power proportionality

Classify each governance-relevant surface (CI configuration, hook configuration, release tooling, instruction files, policy files) on two ordered scales:

Scale	Ordered values
Enforcement power	`blocks-merge` > `blocks-commit` > `warn-only` > `prose-only`
Mandated review	`review-mandatory` > `review-requested` > `none`

blocks-merge means a failing check prevents integration on the protected path (e.g., a required status check); blocks-commit means failure stops a local commit (e.g., an enforced hook); warn-only surfaces report but do not stop; prose-only rules live in text alone. review-mandatory means the surface's own change path requires review before merge; review-requested means review is solicited but not enforced. Vendor mechanisms are examples only — classify by function. Record unknown for a class that cannot be confirmed from the session (host-side enforcement configuration is often readable only through the platform interface — note the evidence lane) and assert no inversion involving an unknown class; classify a surface that enforces at multiple powers by its highest confirmed power.

An inversion exists when one surface has strictly greater enforcement power than another while carrying strictly weaker mandated review (the highest-power surfaces are then the least-reviewed). Phase 6 records the two classes per surface where governance mandates review and flags inversions review-power-inversion (§8.7), citing both surfaces. Phase 4's claimed-automation-absent check uses the same power classes when testing whether a claimed gate is implemented. This is an evidence target consumed by §11 scoring; it adds no scored dimension.

10. Worked Mini-Example

Subject: a TypeScript monorepo with packages/api, packages/agent, packages/domain, packages/db, plus a subagent at packages/agent/subagents/categorizer and an MCP-like server exposing agent tools.

Phase 1 finding

{
  "term": "Transaction",
  "definitions": [
    { "unit": "packages/domain", "definition": "A domain event representing a money movement",
      "citations": [{"path":"packages/domain/src/transaction.ts","lines":"12-45","evidence":"export class Transaction { ... }","method":"view"}] },
    { "unit": "packages/db", "definition": "A database transaction scope (BEGIN/COMMIT)",
      "citations": [{"path":"packages/db/src/tx.ts","lines":"3-20","evidence":"export class Transaction { begin() ...","method":"view"}] }
  ],
  "collision": true,
  "collision_type": "same-term-different-meaning"
}

Phase 2 consequence

db.Transaction should be renamed (e.g., DbTxScope) or namespaced. Recorded as collision finding; no rename performed.

Phase 3 consequence

The categorizer subagent is invoked at packages/agent/src/orchestrator.ts:142. Invocation crosses an authority boundary: main agent has read-write access to user data; subagent is intended to be read-only over a curated chunk. The MCP-like server also exposes categorize_transaction as a callable tool. Record both sides, the protocol surface, and the execution mode.

Phase 4 consequence

The categorizer subagent invocation passes input as unknown (no typed message). The MCP-like tool has a name and description but no machine-readable input schema or authorization metadata. Flag subagent-boundary-untyped, tool-without-schema, and mcp-surface-uninventoried. Recommend a typed boundary schema and a protocol-surface registry.

Phase 5 consequence

The transactions table in packages/db/schema.ts is the authoritative store for the domain Transaction. Classify authoritative-durable, owner_context: billing. The bounded context's authority_basis includes authoritative-store.

Phase 6 consequence

The categorizer subagent has no explicit readable_scopes, approval_mode, bypass-mode statement, or protocol token-scope declaration. Flag subagent-without-policy, approval-precedence-unclear, and remote-agent-token-scope-unknown. Recommend an authority manifest at packages/agent/subagents/categorizer/manifest.json.

Phase 8 consequence

packages/agent/prompts/categorize.md:14 reads "Transactions over $10,000 require manager approval." Phase 8.0 classifies the surface as runtime-production-prompt. Phase 8.1 classifies as embedded-policy (currency + threshold + role in one breath). Recommend extraction to packages/domain/src/approval-policy.ts with a unit test.

Phase 9 consequence

The categorizer subagent and exposed protocol tool have no eval suite. Flag subagent-surface-uncovered, protocol-surface-uncovered, and approval-path-untested. Recommend an offline eval suite + a calibration suite if scoring uses an LLM judge.

Phase 10 finding (current-state list)

{
  "id": "F-007", "title": "Categorizer subagent and protocol tool boundary is untyped, unauthored, and unevaluated",
  "dimension": "tool-surface-clarity", "severity": 4, "confidence": 0.9,
  "status": "active", "strategic_relevance": "direct",
  "snapshot_evidence": [
    {"path":"packages/agent/src/orchestrator.ts","lines":"142-160","evidence":"invokeCategorizer(...)","method":"view"}
  ],
  "smoke_test": "confirmed-current",
  "related_fitness_functions": ["FF-003"],
  "recommendation_boundary": "Boundary contract + protocol registry + authority manifest + eval suite. Does not require subagent rewrite."
}

Phase 10 fitness function (future-protection list)

{
  "id": "FF-003", "title": "Subagent and protocol-boundary discipline",
  "rule": "Every subagent or protocol-exposed agent boundary must declare a typed message contract, protocol registry entry, authority manifest, and eval suite.",
  "enforcement_category": "protocol-contract-registry",
  "scope": "packages/agent/subagents/*",
  "failure_condition": "missing manifest.json, missing protocol registry entry, missing schema.ts, or missing eval suite for any subagent/protocol-exposed agent capability",
  "ff_bucket": "agent-runtime-discipline",
  "related_findings": ["F-007"]
}

Phase 10.5 smoke-test

Re-grep packages/agent/prompts/categorize.md:14 against current development. Possible outcomes:

Line still reads as cited → confirmed-current.
Line moved to line 18 because a header was added → re-evidenced (citation updated).
Prompt was rewritten and threshold removed → struck (kept in log; absent from final priority).
New prompts also embed thresholds → promoted (operator notice).
Prompt was reworded but threshold retained as >$8000 → demoted if scope shrank, or re-evidenced if equivalent.

11. Scoring Rubric

Score each dimension 0–3 with evidence. Aggregate score is informational; the lowest dimensions matter most.

11.1 Bounded contexts

0: No meaningful context distinctions.
1: Names suggest contexts, but vocabulary, stores, or policy ownership collide.
2: Distinct vocabulary and mostly distinct authority, with leaks.
3: Context boundaries are machine-verifiable and pass fitness functions.

11.2 Domain/application separation

0: Business rules live primarily in controllers, adapters, prompts, scripts, or UI.
1: Domain concepts exist but I/O, framework, or provider dependencies leak in.
2: Domain is pure for most contexts; occasional leaks exist.
3: Domain purity and dependency direction are enforced.

11.3 Contract discipline

0: External interfaces are mostly ad hoc.
1: Partial schema coverage; producer/consumer or validation unclear.
2: Most external interfaces are schema-defined; versioning, compatibility, protocol object separation, or workflow-overlay linkage is inconsistent.
3: Interfaces (HTTP, RPC, workflow descriptions, overlays, MCP tools/resources/prompts/roots, protocol tasks and extensions, A2A Agent Cards/skills/tasks, subagents, callbacks, provenance, cross-agent instruction contracts, agent-skill packages) are machine-defined, versioned, validated, and diff-gated.

11.4 Tool/action surface clarity

0: Tools/actions overlap, have vague names, or lack schemas.
1: Tools/actions are named with partial schemas but overlap or authority ambiguity exists.
2: Tools/actions/resources/prompts/skills are distinct, schema-defined, protocol objects are mostly separated, and overlap is limited.
3: Registry includes descriptions, schemas, protocol versions, authority scopes, approval policies, lifecycle modes, and version pins.

11.5 State and memory clarity

0: Memory/state is conflated or implicit.
1: Some stores are identified, but lifecycle, owner, or authority is unclear.
2: Stores and memory surfaces are classified with retention, owners, and delete/reset paths for request-local, session, durable conversation, long-term memory, retrieval corpus, retrieval index, artifact, and operator-rules classes.
3: Store registry is machine-readable and retention, deletion, invalidation, and authority are enforced by class.

11.6 Authority boundaries

0: Broad default access; write capabilities not scoped.
1: Authority documented informally.
2: Per-tool/action/principal authority declared with approval gates for write paths, but bypass/precedence/callback/secondary-credential handling may have gaps.
3: Capability-scoped authority is enforced per invocation and audited; approval precedence, bypass modes, secondary credentials, callbacks, hosted/local boundaries, and computer-use/browser-use/filesystem-use sandboxes are verifiable.

Repo-operating agents (note). Where repo-operating agents are in scope, committed authority configuration for those agents is assessed here separately from product-runtime principals. Evidence may include readable/writable scopes, approval precedence, bypass and protected-path behavior, sandbox or workspace roots, hosted/local execution boundaries, and source-pinning or lockdown controls for customization layers (skills, hooks, plugins, protocol-server configuration). Name capabilities, not vendor files; vendor-specific paths are examples only. If no such configuration exists, record whether that is not applicable, unknown, or an authority gap based on the repo's claimed operating model. Where isolation is claimed for repo-operating, computer-use, or browser-use agents, current baseline evidence includes OS-level or micro-VM isolation, filesystem write-allowlists, secret-path read denials, and default-deny network egress with an explicit allowlist; an approval gate alone is not isolation evidence.

11.7 Observability semantics

0: Logs only or no meaningful telemetry.
1: Structured telemetry exists but naming and units are inconsistent.
2: Traces/metrics/logs align with chosen conventions for most critical paths; semantic-convention version/stability, provenance class, or eval linkage gaps remain.
3: Stable semantic telemetry, cost/latency/quality attribution, runtime/action provenance, relevant content/build provenance positions, and eval-result correlation are enforced.

11.8 Policy/prompt separation

0: Prompts or instructions carry product, authority, or release policy.
1: Some policy extracted, but prompt-only rules remain.
2: Runtime and server-exposed prompts are mostly parameterized from policy-controlled sources; authoring artifacts or privileged-context boundaries may drift.
3: Prompt surfaces are classified, server-exposed prompts are contracted, untrusted input boundaries are controlled, policy homes are explicit, and drift is fitness-function checked.

11.9 Evals and quality gates

0: No eval coverage for model/agent/automation paths.
1: Ad hoc examples or manual review only.
2: Critical paths have evals, golden data or rubrics, and partial CI/release integration.
3: Coverage registry, versioned datasets/evaluators, CI and release gates, trace-linked quality results, and LLM-judge calibration.

11.10 Governance and audit trail

0: Decisions and rules are tribal knowledge.
1: Some docs/ADRs exist but precedence and supersession are unclear.
2: Governance artifacts are current enough to guide the audit; some drift remains.
3: ADRs, conventions, cycle history, and fitness functions are current, explicit, and validated. ADR template includes "Decides / Scopes to / Does not decide / Carve-outs" sections.

Standing decision ledger (note). Evidence here includes whether the project maintains a standing decision ledger — durable ids that are never reused, with queued/rejected/open statuses — distinct from its ADR record and from audit-cycle history, with ledger and ADRs cross-referencing (an ADR carries a decision event's rationale; the ledger is the "is this settled?" index). If none exists, record whether that is not applicable, unknown, or a governance gap given the project's decision volume.

11.11 Architectural fitness functions

0: None.
1: Rules documented but not enforced.
2: Some automated checks exist.
3: Comprehensive CI/release gates cover dependency direction, schemas, protocol-contract registries, authority matrices, memory lifecycle, telemetry, prompts, evals, provenance, companion-doc drift, and governance templates.

Negative self-tests (note). An implemented fitness function with non-trivial matching logic earns full credit here only when a negative self-test runs wherever the function runs; without one, credit it as partially verified — a matcher that can rot silently is weaker enforcement evidence (Phase 10 step 8, §8.12 negative_self_test).

11.12 Strategic-theme default-mapping

When an operator supplies a theme without an explicit dimension list, apply this default:

Theme	Weighted dimensions (1.5× direct)
`sdk-extraction`	11.3 Contract discipline, 11.4 Tool surface, 11.6 Authority, 11.1 Bounded contexts
`multi-tenant-isolation`	11.6 Authority, 11.5 State, 11.1 Bounded contexts
`regulatory-readiness`	11.6 Authority, 11.7 Observability, 11.9 Evals, 11.3 Contract discipline
`agent-safety-hardening`	11.6 Authority, 11.7 Observability, 11.8 Policy/prompt separation
`eval-coverage`	11.9 Evals, 11.7 Observability, 11.4 Tool surface
`cost-attribution`	11.7 Observability, 11.5 State, 11.3 Contract discipline
`agent-runtime-consolidation`	11.4 Tool surface, 11.1 Bounded contexts, 11.6 Authority
`legacy-migration`	11.1 Bounded contexts, 11.2 Domain/application, 11.3 Contract discipline
`agent-operability`	11.3 Contract discipline, 11.6 Authority, 11.10 Governance, 11.11 Architectural fitness functions

For agent-operability, §11.8 Policy/prompt separation may be indirectly relevant when skill/SOP content carries product, authority, or release policy.

Operators may override; custom themes name their own dimensions.

12. Priority and Remediation Handoff

The audit may recommend fix order, but remediation planning is a separate directive.

Default fix order:

vocabulary and bounded contexts;
contracts and schemas;
authority boundaries;
state and memory boundaries;
runtime and orchestration boundaries;
policy/prompt separation;
observability semantics;
evals and quality gates;
governance and ADR cleanup;
fitness functions to lock in the intended architecture.

The audit must preserve this distinction:

Audit: identifies and scores structural evidence.
Planning: decides PR units, ordering, ADR decisions, split rules, and implementation sequence.
Remediation: changes code or governance artifacts.

13. Deliverables Manifest

audit/<date>/
  00-scope.md
  00-scope.json
  00-reference-anchors.json
  profile-diff.md                 # only on re-runs (consumed from profile)
  01-vocabulary.md
  01-vocabulary.json
  02-context-map.md
  02-contexts.json
  02-context-map.mmd
  03-runtime.md
  03-runtime.json
  03-loops/*.mmd
  04-contracts.md
  04-contracts.json
  05-state.md
  05-state.json
  06-authority.md
  06-authority.json
  07-observability.md
  07-observability.json
  08-policy.md
  08-policy.json
  08-prompt-surfaces.json
  09-evals.md
  09-evals.json
  10-findings.md
  10-findings.json
  10-scores.json
  10-fitness-functions.md
  10-fitness-functions.json
  10.5-finding-smoke-test.md
  10.5-finding-smoke-test.json
  cycle-history-notes.md
  halt.md                         # only if halted
  halt-stale-evidence.md          # only on Phase 10.5 stale-rate halt
  halt-investigation/             # only if recovery required
  SUMMARY.md

SUMMARY.md is the operator entry point and contains:

audit mode and profile snapshot date;
score table;
top findings by priority (smoke-tested form);
active strategic themes and their effects on prioritization;
profile/current-branch drift summary;
proposed fitness functions;
caveats and halt/resume history;
recommended next audit cadence;
pointer to detailed phase artifacts.

The agent's final chat message is a one-line pointer to audit/<date>/SUMMARY.md. No substitute summary.

14. Reference Anchors to Version-Pin at Audit Time

The agent must check current official sources when an audit run depends on current versions or semantic conventions. At minimum, version-pin:

OpenAPI Specification for HTTP API descriptions.
Arazzo or equivalent workflow-description specification when workflow contracts exist.
Overlay or equivalent API augmentation specification when overlays exist.
JSON Schema for structured payload validation.
Model Context Protocol, including security, authorization, roots, tools, resources, resource templates, prompts, sampling, elicitation, completion, task, extension (including server-delivered UI extensions), and registry/discovery behavior, if MCP or MCP-like surfaces exist. Record the lifecycle status (core, extension, experimental, deprecated) of each protocol object in use at the pinned revision — protocol objects move between these states across revisions.
OpenTelemetry semantic conventions, including GenAI, agent, and MCP conventions when model-mediated or protocol-mediated paths exist. Record both version and stability status.
A2A / inter-agent protocols, including Agent Cards (and their signatures), skills, task states, streaming, push notifications, registries, and authentication if such surfaces exist.
Agent-skill specifications (cross-tool skill-package formats: frontmatter contracts, capability pre-approvals, progressive disclosure) when agent-skill packages exist.
Agent identity and delegated-authorization standards (identity-chaining and token-exchange grants, signed-agent identity, workload identity) when agents act across identity boundaries.
Agentic commerce and payment-delegation protocols (verifiable intent mandates, delegation scopes, settlement identity binding) when an agent can initiate or approve payments.
Provenance standards separately for runtime/action records, content credentials, and build/source attestations where applicable.
Regulatory transparency obligations for machine-detectable marking of synthetic content, in jurisdictions where they apply, when content-provenance positions are in scope.
Cost-attribution specifications for AI workloads (token- and workload-level cost breakdown conventions) when cost attribution is in scope.
Relevant model-provider or agent-framework documentation for tool use, handoffs, guardrails, tracing, and evals.
NIST AI RMF and related agent-security control overlays and agent-identity guidance when AI risk-management findings are in scope.
OWASP GenAI / LLM / agentic / MCP risk materials, including the agentic-applications and agentic-skills risk lists, when security or safety findings are in scope.
Computer-use and browser-use sandboxing patterns from current vendor guidance.

Do not assume the agent's training data reflects current versions. Record the pinned version of each anchor in 00-scope.md.

15. Global Boundary Declarations

Per-step boundaries are declared inline at each phase. The following apply globally. The agent must not:

modify source code;
recommend folder moves during audit phases;
infer bounded contexts from folder names alone;
cite sources it cannot read in-session;
equate schema presence with contract discipline absent registry, validation, producer/consumer mapping, or versioning;
collapse MCP, A2A, workflow, callback, or remote-agent protocol surfaces into a generic "tool" finding when the concrete objects can be inventoried;
skip halt conditions;
produce SUMMARY.md before phases 0–10.5 artifacts exist;
use hook-bypass or verification-bypass mechanisms (--no-verify and equivalents);
produce prose findings without citations;
paper over contradictions with speculation;
expand scope without operator direction;
silently correct stale evidence;
collapse current-state findings and future-state fitness functions into one ID;
treat non-runtime prompt artifacts as irrelevant without classification;
treat server-exposed prompts as documentation-only;
treat approval presence as sufficient without checking precedence, bypass modes, protected paths, secondary credentials, callbacks, and enforcement;
conflate request-local state, session state, durable conversation state, long-term memory, retrieval corpora, retrieval indexes, artifacts, and operator-authored persistent rules;
conflate runtime/action provenance, content provenance, and build/source provenance;
score missing development-stage semantic conventions as strictly as missing stable conventions without recording stability status;
treat a protocol object list remembered from training data as current rather than inventorying objects against the pinned protocol revision;
classify an agent-skill package as prose governance alone when it declares machine-readable metadata, capability pre-approvals, or bundled executables;
weight findings by severity alone if a strategic theme is supplied;
edit profile/cycle-history.md directly (audit proposes via cycle-history-notes.md; profile commits).

16. Versioning

This specification is v3.5 dated 2026-06-10.

Breaking changes bump the major version. Additive schema fields, additional examples, or clarification of existing behavior bump the minor version. Patch versions correct wording without changing behavior.

Each audit records:

audit spec version;
profile directive version;
profile snapshot date;
current branch and revision;
audit mode;
strategic themes, if any;
pinned versions of reference anchors used during the audit (§14).

Changes from v2.0:

Added Phase 10.5 finding smoke-test with eight outcome states.
Added Phase 8.0 prompt-surface classification and Phase 8.1 policy treatment.
Added §1 directive-as-handoff operating model with audit-mode enum.
Added §4.3 halt-recovery state machine.
Generalized SDK-relevance to multi-theme strategic weighting (§11.12 default-mapping table).
Promoted prohibitions to per-step boundary declarations inline at each phase.
Separated Phase 10 findings into structural-current-state (F-NNN) and missing-safeguard (FF-NNN) lists with independent IDs.
Added subagent, computer-use, browser-use, durable-workflow, A2A surfaces to Phases 3, 4, 6, 7, 9.
Added provenance to the cost/latency/quality observability quartet.
Added LLM-as-judge calibration as a distinct eval mode.
Added context-assembly logic (retrieval filters, tool descriptions, skills/SOPs) to Phase 8 scope.
Citation schema gained evidence, method, snapshot_ref, current_ref fields.
BoundedContext status enum gained rejected | merged | split outcomes; added authority_basis field.
Finding schema gained confidence, strategic_relevance, snapshot_evidence, current_evidence, smoke_test.
Scoring rubric expanded from 8 to 11 dimensions (separate Policy/prompt, Evals, Governance, Fitness functions).
Audit emits cycle-history-notes.md as proposals only; profile directive owns commits to profile/cycle-history.md.
Caveat classification (substantive / cosmetic / exact-match) made first-class in §9.6.
Reference anchors expanded to include NIST AI RMF and OWASP GenAI materials.

Changes from v3.0:

Added protocol-aware inventory for MCP tools, resources, resource templates, prompts, roots, sampling, elicitation, completion, and authorization metadata.
Added A2A Agent Card, advertised skill, task-state, streaming, push-notification, registry, and authentication handling.
Added workflow-description and overlay contract handling alongside API descriptions and schema dialect pinning.
Expanded execution-mode taxonomy to cover background, paused-for-approval, resumable, durable, callback-mediated, and event-triggered paths.
Replaced simple authority fields with authority-matrix requirements covering approval mode, precedence, bypass modes, protected paths, secondary credentials, callback authentication, hosted/local boundaries, and token delegation.
Split state and memory into request-local state, session state, durable conversation state, long-term memory, retrieval corpus, retrieval index, artifact store, evaluation dataset, checkpoint state, and operator-authored persistent rules/memory.
Split provenance into runtime/action, content, and build/source classes.
Added semantic-convention version and stability-status pinning.
Added server-exposed prompt classification and privileged-context injection checks.
Added protocol, approval, async lifecycle, and memory lifecycle eval coverage flags.
Added companion-artifact drift controls for kickoff prompts, friendly explainers, manifests, examples, and other derived guidance.

Changes from v3.1:

Added first-class handling of the cross-agent instruction contract: AGENTS.md is recognized as the canonical, tool-agnostic instruction standard, with CLAUDE.md/GEMINI.md/.cursor/rules as bridges that should import or defer to it (§5.1, §6.3).
Phase 4 now inventories the canonical↔bridge relationship and flags cross-agent-instruction-drift (a tooling-agnostic project with no canonical AGENTS.md, or bridges that diverge from or duplicate it).
Added the cross-agent-instruction surface and cross-agent-instruction-drift flag to the Contract schema (§8.5), and added cross-agent instruction contracts to the Contract-discipline rubric (§11.3).
Additive only: v3.1 audits remain valid; the Profile Directive (v1.4) is unaffected and its profiles are consumed unchanged.

Changes from v3.2:

Added the agent-operability strategic-theme lens (§2.3 examples + §11.12 default-mapping), reweighting §11.3/§11.6/§11.10/§11.11 at 1.5× without adding a scored dimension (rationale: adr/0001-agent-operability-as-theme.md).
Added a repo-operating-agent authority clause to §11.6 (committed dev-time authority configuration, a distinct principal from product-runtime).
Added a developer-agent-workflow scope boundary to §0.
Additive only: v3.2 audits remain valid; the Profile Directive (v1.4) is consumed unchanged.

Changes from v3.3:

Elevated agent-skill packages to first-class contracts and authority surfaces (§5.1, §6.3, Phase 4, Phase 6, §8.5, §8.7, §9.1, §11.3, §14): frontmatter contracts, capability pre-approvals (e.g., allowed-tools), bundled executables, and source/marketplace provenance are inventoried and flagged (skill-frontmatter-invalid, skill-authority-undeclared, skill-provenance-unvetted).
Added protocol-object lifecycle status recorded against the pinned protocol revision (Phase 0 step 6, Phase 4, §8.5 protocol_object_status, §14), so the inventory tracks deprecations and extensions instead of hard-coding an object list; added protocol tasks, extension declarations, server-delivered UI surfaces, and registry/discovery metadata as inventoryable objects (Phases 3, 4, 6, 8; §8.4, §8.5, §9.1).
Added agent identity and delegated commerce evidence targets to Phase 6 and the authority matrix (§9.7 rows; commerce-delegation-unbounded, commerce-mandate-missing flags). Commerce checks apply only where an agent can initiate or approve payments.
Added customization supply-chain checks (skills, hooks, plugins, protocol-server configuration consumed by repo-operating agents) under the agent-operability lens (§2.3, Phase 6, §8.7 customization-source-unpinned, §11.6 note).
Added a hosted-eval platform-lifecycle flag (Phase 9, §8.10 eval-platform-deprecated).
Calibrated the §11.6 isolation-baseline note (OS-level or micro-VM sandbox, filesystem write-allowlists, secret-path read denials, default-deny egress).
Refreshed the §14 reference anchors (agent-skill specifications, agent identity and delegated authorization, agentic commerce, synthetic-content transparency obligations, AI cost-attribution conventions).
Additive only: v3.3 audits remain valid. Profiles from Directive v1.4 are consumed unchanged; Directive v1.5 adds optional discovery fields this specification consumes when present.
Rationale recorded in adr/0002-skills-as-contracts-and-protocol-object-lifecycle.md.

Changes from v3.4:

Added a per-cycle id-durability discipline (Phase 10 step 4, §10.2; optional cycle field in §8.11/§8.12): ids are either monotonic-never-reused across cycles or cycle-qualified wherever cited in artifacts that outlive their cycle; the anchored in-run id patterns are unchanged, and dated cycle artifacts keep bare ids.
Added typed citation provenance to §8.1: optional observed_at, valid_until, and evidence_lane (repo-local | host-verifiable | unavailable) extending snapshot_ref/current_ref — which revision vs. when captured, how long trustable, and through what channel re-verifiable — with Phase 10.5 recording not-run through the lane and §1.2 noting per-citation freshness for steady-state/focused-diff consumers.
Added the claimed-automation-absent flag (Phase 4, §8.5): governance or instruction text claiming automated enforcement with no implemented gate, routed to Phase 9 for gate confirmation using the §9.9 power classes; approval-gate claims on authority principals remain approval-not-enforced (Phase 6, §8.7), and honestly-manual rules are not flagged.
Added the instruction-reference-broken flag (Phase 4, §8.5): instruction contracts citing repository artifacts that do not resolve in the tree; environment-resolved commands are out of scope, and content staleness remains Phase 8.
Added the §9.9 review-power proportionality matrix and review-power-inversion flag (Phase 6, §8.7): ordered enforcement-power (blocks-merge > blocks-commit > warn-only > prose-only) and mandated-review scales with a decidable pairwise inversion condition.
Added the regression-trap eval-suite mode (Phase 9, §8.10): behavioral traps seeded from observed agent failures, distinct from golden-data regression and code regression tests, with the existing Phase 10.5 demotion rule applied — an unharnessed trap corpus is manual-review-only, not coverage.
Added metalanguage containment (Prime Directive 16, Phase 1 step 6, Phase 5 note, §8.2): audit-internal taxonomy is never exported into project vocabulary; the Phase 1 collision check gains the audit-taxonomy-collision type against profile-declared forbidden terms; machine-readable schema fields keep taxonomy values.
Added operating-agent baseline drift checks (Phase 6, §8.7 model-alias-resolution-drift): where the profile records operating-agent CLI versions, model posture, and model-alias pins, the audit confirms each pin still resolves to the recorded baseline.
Added an agent-memory truth-maintenance evidence target (Phase 5, §8.6 optional truth_maintenance, prose flag memory-truth-maintenance-absent): whether agent-held claims have a correction path when repository facts change, extending invalidation_trigger.
Added a negative-self-test rule for implemented fitness functions (Phase 10 step 8, §8.12 optional negative_self_test, §11.11 note): a non-trivially-matching implemented fitness function without a negative self-test earns reduced credit.
Added a standing-decision-ledger evidence target (§11.10 note; decision ledgers join the Phase 8.1 policy-artifact locate list).
Additive only: v3.4 audits remain valid. Profiles from Directive v1.5 are consumed unchanged; Directive v1.6 adds optional discovery fields this specification consumes when present.
Rationale recorded in adr/0004-evidence-discipline-and-enforcement-honesty.md.

Appendix A — Migration from v2 to v3.x

For projects with a v2 audit cycle on file:

Run the profile discovery directive (current version per MANIFEST.md) to refresh the profile (it emits diff artifacts, strategic-themes blocks, and protocol/authority/state/provenance baselines).
Initialize profile/cycle-history.md from the v2 cycle's directive series — the prior cycle becomes "cycle 1, retrospective entry."
First v3.x cycle inherits v2 conventions; record them in cycle-history.md rather than restating them in directives.
Run Phase 10.5 against the v2 findings list as a one-time validation (catches drift accumulated since v2 ship).
Apply strategic-theme weighting; if no theme was specified at v2 time, treat as none and re-run Phase 10 prioritization.

The diff between v2 and v3 outputs is itself useful audit signal — it shows what the older spec missed.

Appendix B — Migration from v3.0 to v3.1

For projects with a v3.0 audit cycle on file:

Preserve the v3.0 audit artifacts as the historical record.
Run the profile discovery directive (current version per MANIFEST.md) to refresh protocol, authority, state, provenance, and companion-artifact fields.
In Phase 0, record v3.0-to-v3.1 drift separately from code drift.
Re-run Phases 3–8 and 9 for any project exposing MCP, A2A, background/resumable execution, server-exposed prompts, or durable memory.
Re-score Phases 10 and 10.5 only after protocol surfaces, authority matrix, memory classes, semconv stability, and provenance classes have been pinned or marked not applicable.

Appendix C — Migration from v3.1 to v3.2

For projects with a v3.1 audit cycle on file:

Preserve the v3.1 audit artifacts as the historical record.
Re-run Phase 4 to inventory the cross-agent instruction contract: confirm a canonical AGENTS.md exists and that any tool-specific files (CLAUDE.md, GEMINI.md, .cursor/rules) import or defer to it rather than diverging.
Flag cross-agent-instruction-drift where a tooling-agnostic project ships only tool-specific instructions, or where bridges duplicate or contradict the canonical file.
No other phase changes; v3.1 findings remain valid, and the Profile Directive (v1.4) is consumed unchanged.

Appendix D — Migration from v3.2 to v3.3

For projects with a v3.2 audit cycle on file:

Preserve the v3.2 audit artifacts as the historical record.
Optionally adopt the agent-operability strategic theme (§11.12) for a coherent operability reading; it reweights existing dimensions and adds no scored dimension, so prior scores are unaffected.
Where repo-operating agents are in scope, assess their committed authority configuration under §11.6 (distinct from product-runtime principals).
No phase or scoring change; v3.2 findings remain valid, and the Profile Directive (v1.4) is consumed unchanged.

Appendix E — Migration from v3.3 to v3.4

For projects with a v3.3 audit cycle on file:

Preserve the v3.3 audit artifacts as the historical record.
Re-run Phase 4 where agent-skill packages exist: inventory each skill's frontmatter contract, capability pre-approvals, bundled executables, and source provenance; route capability grants to Phase 6.
In Phase 0, re-pin protocol revisions per §14 and record the lifecycle status of each protocol object in use; flag protocol-object-deprecated where the project relies on objects deprecated at the pinned revision without a migration position.
Re-run Phase 4 and Phase 6 for protocol tasks, extension declarations (including server-delivered UI), registry/discovery metadata, and — only where an agent can initiate or approve payments — delegated-commerce contracts.
No scoring change: prior dimension scores remain valid. New flags surface as new findings against the same rubric.

Appendix F — Migration from v3.4 to v3.5

For projects with a v3.4 audit cycle on file:

Preserve the v3.4 audit artifacts as the historical record.
Record the cycle's id discipline (monotonic-never-reused, or cycle-qualified citation) once in Phase 10; prior cycles' ids are not retro-edited — dated artifacts keep bare ids.
Where governance or instruction text claims automated enforcement, re-run the Phase 4 flag checks (claimed-automation-absent, instruction-reference-broken) and confirm claimed gates in Phase 9.
Where governance mandates review, classify enforcement power and mandated review per §9.9 in Phase 6 and flag inversions; where the profile records operating-agent alias pins, confirm each pin's current resolution.
The optional fields (cycle, observed_at, valid_until, evidence_lane, truth_maintenance, negative_self_test) backfill lazily — their absence in v3.4 artifacts is not drift.
No scoring change: prior dimension scores remain valid. New flags surface as new findings against the same rubric.

FilesExpand file tree

audit-spec.md

Latest commit

History

audit-spec.md

File metadata and controls

Agentic Architecture Audit — Agent Specification v3.5

0. Purpose

1. Operating Model: Directive-as-Handoff

1.1 Snapshot model

1.2 Audit mode

2. Inputs

2.1 Required inputs

2.2 Conditional inputs

2.3 Strategic themes

3. Prime Directives

4. Halt and Recovery

4.1 Halt conditions

4.2 Halt artifact contents

4.3 Halt-recovery state machine

5. Target Architecture Model

5.1 Planes

5.2 Alignment principle

6. Classification Model

6.1 Primary categories

6.2 Mixed classification

6.3 Tie-breakers

6.4 Secondary tags

7. Phased Workflow

Phase 0 — Scope, Snapshot, and Orientation

Phase 1 — Domain Vocabulary Extraction

Phase 2 — Bounded Context Mapping

Phase 3 — Runtime Map

Phase 4 — Contract Inventory

Phase 5 — State and Memory Inventory

Phase 6 — Authority Boundaries

Phase 7 — Observability Semantics

Phase 8 — Policy and Prompt / Context Separation

Phase 8.0 — Prompt-surface classification

Phase 8.1 — Policy separation treatment

Phase 9 — Evals and Quality Gates

Phase 10 — Findings, Scoring, and Fitness Functions

10.1 Finding priority

10.2 Finding vs. fitness function separation

Phase 10.5 — Finding Smoke-Test

Phase 11 — Summary and Cycle-History Notes

8. Output Schemas

8.1 Citation

8.2 VocabularyTerm

8.3 BoundedContext

8.4 Entrypoint

8.5 Contract

8.6 Store

8.7 Authority

8.8 TelemetrySignal

8.9 PromptSurface

8.10 EvalSuite

8.11 Finding

8.12 FitnessFunction

9. Decision Matrices

9.1 Tool vs. Resource vs. Prompt vs. Workflow

9.2 Agent or automation split justification

9.3 Sync vs. async vs. durable boundary

9.4 Embedded policy in prompts and contexts

9.5 Strategic relevance

9.6 Caveat classification

9.7 Authority matrix completeness

9.8 Provenance split

9.9 Review-power proportionality

10. Worked Mini-Example

Phase 1 finding

Phase 2 consequence

Phase 3 consequence

Phase 4 consequence

Phase 5 consequence

Phase 6 consequence

Phase 8 consequence

Phase 9 consequence

Phase 10 finding (current-state list)

Phase 10 fitness function (future-protection list)