ai-capability-framework 1.0.0-rc.3 → 1.0.0

package/docs/spec.md

@@ -1,52 +1,52 @@
 # AICF 1.0 Spec
 
-This page defines the normative public contract for AI Capability Framework
-Core (AICF Core) 1.0 manifests and deterministic framework behavior.
+This page defines the normative public contract for AI Capability Framework Core (AICF
+Core) 1.0 manifests and deterministic framework behavior.
 
 AICF Core is a no-execution framework. It describes capabilities, validates public
 contracts, builds registries, evaluates deterministic policy/lifecycle decisions,
-exports adapter metadata, and scores deterministic eval fixtures. It does not
-call models, execute handlers, verify real host authorization, collect
-approvals, persist actions, write durable audit logs, or perform side effects.
+exports adapter metadata, and scores deterministic eval fixtures. It does not call
+models, execute handlers, verify real host authorization, collect approvals, persist
+actions, write durable audit logs, or perform side effects.
 
 ## Manifest Versioning
 
 - Every 1.0 manifest MUST use `schema_version: "1.0"`.
-- AICF 1.0 is a clean cut from the pre-release `0.1` schema. Validators are not
-  required to accept `0.1` manifests.
-- Capability manifests MUST include a semantic `version` for the application
-  capability contract.
-- Breaking changes to manifest fields, validation, or deterministic semantics
-  MUST use a new schema version.
+- AICF 1.0 is a clean cut from the pre-release `0.1` schema. Validators are not required
+  to accept `0.1` manifests.
+- Capability manifests MUST include a semantic `version` for the application capability
+  contract.
+- Breaking changes to manifest fields, validation, or deterministic semantics MUST use a
+  new schema version.
 - Capability behavior changes that affect input, output, policy, side effects,
-  lifecycle, model-facing meaning, or eval expectations MUST update the
-  capability `version`.
+  lifecycle, model-facing meaning, or eval expectations MUST update the capability
+  `version`.
 - Vendor or application-specific fields MUST live under `extensions`.
 
 ## ID Naming
 
 - Capability IDs MUST use at least three dotted lowercase segments, such as
   `support.refund.prepare_case`.
-- Capability ID segments MAY contain lowercase letters, digits, and underscores,
-  and MUST start with a lowercase letter.
+- Capability ID segments MAY contain lowercase letters, digits, and underscores, and
+  MUST start with a lowercase letter.
 - Entity IDs MUST use PascalCase, such as `Ticket` or `MeetingInvite`.
-- Eval IDs MUST use lowercase dotted segments and SHOULD include the capability
-  or behavior under test.
+- Eval IDs MUST use lowercase dotted segments and SHOULD include the capability or
+  behavior under test.
 - Public examples MUST use synthetic IDs and `example.com` contacts only.
 
 ## Autonomy Tiers
 
-- `A0`: Application-only execution. The model MUST NOT directly select or commit
-  the capability in a normal tool set.
+- `A0`: Application-only execution. The model MUST NOT directly select or commit the
+  capability in a normal tool set.
 - `A1`: Read or low-risk assistive behavior.
 - `A2`: Prepare-only behavior that produces a reviewable preview.
 - `A3`: Low-risk commits that policy explicitly allows without approval.
 - `A4`: Higher-risk commits requiring strong policy controls and audit.
-- `A5`: Critical actions. These SHOULD require explicit human approval and
-  separate commit paths.
+- `A5`: Critical actions. These SHOULD require explicit human approval and separate
+  commit paths.
 
-The control plane MUST deny a decision when the request autonomy tier exceeds
-the capability autonomy tier or the capability policy max autonomy tier.
+The control plane MUST deny a decision when the request autonomy tier exceeds the
+capability autonomy tier or the capability policy max autonomy tier.
 
 ## Risk Tiers
 
@@ -58,16 +58,16 @@ the capability autonomy tier or the capability policy max autonomy tier.
   consequential state.
 - `critical`: Irreversible, regulated, privileged, or safety-critical behavior.
 
-Risk tiers are manifest metadata used by AICF Core filters and diagnostics.
-Host applications remain responsible for real enforcement.
+Risk tiers are manifest metadata used by AICF Core filters and diagnostics. Host
+applications remain responsible for real enforcement.
 
 ## Capability Types
 
 - `read_data`: Reads application data.
 - `retrieve_documents`: Retrieves knowledge or source documents.
 - `compute`: Produces deterministic calculations or transformations.
-- `write_prepare_only`: Creates a proposed action or preview without committing
-  the side effect.
+- `write_prepare_only`: Creates a proposed action or preview without committing the side
+  effect.
 - `write_commit`: Commits a previously allowed and verified side effect.
 - `external_message_prepare`: Prepares a message for review.
 - `external_message_send`: Sends a message outside the application.
@@ -75,86 +75,81 @@ Host applications remain responsible for real enforcement.
 - `workflow_step`: Advances a workflow.
 - `human_handoff`: Transfers work to a human queue or reviewer.
 
-Restricted side-effect capabilities SHOULD be excluded from broad model tool
-sets unless the host has narrowed context and verified the required preconditions.
+Restricted side-effect capabilities SHOULD be excluded from broad model tool sets unless
+the host has narrowed context and verified the required preconditions.
 
 ## Capability Manifests
 
-A capability manifest MUST define model-selectable behavior, inputs, outputs,
-risk, autonomy, side effects, authorization requirements, policy gates,
-lifecycle flags, observability expectations, and optional eval links.
+A capability manifest MUST define model-selectable behavior, inputs, outputs, risk,
+autonomy, side effects, authorization requirements, policy gates, lifecycle flags,
+observability expectations, and optional eval links.
 
 Schemas are strict by default with `additionalProperties: false`. The embedded
 `input_schema` and `output_schema` fields are JSON Schema objects owned by the
-capability author. AICF Core validators MUST compile these embedded schemas and
-SHOULD fail object-incompatible callable input schemas.
+capability author. AICF Core validators MUST compile these embedded schemas and SHOULD
+fail object-incompatible callable input schemas.
 
 Capability `status` controls default selection:
 
-- `active`: selectable when policy, lifecycle, risk, context, and adapter
-  filters allow it.
+- `active`: selectable when policy, lifecycle, risk, context, and adapter filters allow
+  it.
 - `disabled`: denied and never exported by default.
-- `deprecated`, `draft`, and `experimental`: excluded by default and selectable
-  only with explicit compatibility, development, or test options.
+- `deprecated`, `draft`, and `experimental`: excluded by default and selectable only
+  with explicit compatibility, development, or test options.
 
-`authorization.permissions` declares deterministic permission strings required
-by the control plane. AICF checks that the request context includes them; host
-applications MUST enforce real identity, tenant, and permission state.
+`authorization.permissions` declares deterministic permission strings required by the
+control plane. AICF checks that the request context includes them; host applications
+MUST enforce real identity, tenant, and permission state.
 
 ## Entity Manifests
 
-An entity manifest MUST describe a model-relevant application entity, canonical
-ID field, data classification, lookup path, allowed actions, and model guidance.
+An entity manifest MUST describe a model-relevant application entity, canonical ID
+field, data classification, lookup path, allowed actions, and model guidance.
 
-Entity manifests are descriptive. They do not grant access to records and do not
-replace application data models or authorization.
+Entity manifests are descriptive. They do not grant access to records and do not replace
+application data models or authorization.
 
 ## Eval Case Manifests
 
-An eval case manifest MUST describe deterministic expected behavior for a
-synthetic user input. Evals MAY cover tool selection, argument extraction,
-policy decisions, approval boundaries, refusals, response text, and no-commit
-constraints.
+An eval case manifest MUST describe deterministic expected behavior for a synthetic user
+input. Evals MAY cover tool selection, argument extraction, policy decisions, approval
+boundaries, refusals, response text, and no-commit constraints.
 
-Eval cases MUST be public-safe when committed to this repository. They MUST NOT
-contain raw prompts, raw traces, provider payloads, customer records, secrets,
-internal endpoints, or private documents.
+Eval cases MUST be public-safe when committed to this repository. They MUST NOT contain
+raw prompts, raw traces, provider payloads, customer records, secrets, internal
+endpoints, or private documents.
 
 ## Eval Result Fixtures
 
-An eval result fixture MUST use `schema_version: "1.0"` and contain `results`.
-Each result is keyed by `eval_id` and MAY include selected capabilities, tool
-calls, policy decision, action state, committed capabilities, refusal metadata,
-response text, and `extensions`.
+An eval result fixture MUST use `schema_version: "1.0"` and contain `results`. Each
+result is keyed by `eval_id` and MAY include selected capabilities, tool calls, policy
+decision, action state, committed capabilities, refusal metadata, response text, and
+`extensions`.
 
-The eval runner scores summarized candidate behavior only. It MUST NOT call
-models, ingest raw provider payloads, execute capabilities, or store traces.
+The eval runner scores summarized candidate behavior only. It MUST NOT call models,
+ingest raw provider payloads, execute capabilities, or store traces.
 
 ## Policy Semantics
 
-The deterministic control plane evaluates policy from manifest metadata plus a
-request context.
+The deterministic control plane evaluates policy from manifest metadata plus a request
+context.
 
 - Missing required permissions MUST deny.
-- If `authorization.requires_user_context` is true, missing `context.userId`
-  MUST deny.
-- If `authorization.tenant_scoped` is true, missing `context.tenantId` MUST
-  deny.
+- If `authorization.requires_user_context` is true, missing `context.userId` MUST deny.
+- If `authorization.tenant_scoped` is true, missing `context.tenantId` MUST deny.
 - Requested autonomy above capability or policy max MUST deny.
-- Context `riskCeiling` and `allowedRiskTiers` MUST deny capabilities outside
-  the requested risk boundary.
-- `prepare` and `commit` requests MUST include args that validate against the
-  capability `input_schema`. `select` MAY omit args, but supplied select args
-  MUST validate.
-- `deny_if` checks `facts[rule]`. A true fact MUST deny, a false fact allows
-  evaluation to continue, and a missing fact MUST fail closed by denying unless
-  a rule explicitly sets `missing_behavior: ignore` or
-  `missing_behavior: approval_required`.
-- `approval_required_if` evaluates field paths against request args. Missing
-  fields on medium, high, or critical capabilities MUST fail closed to approval
-  required unless the rule explicitly overrides `missing_behavior`.
-- `policy.approval_required` MAY produce an approval-required prepare decision,
-  and MUST block commit unless approval is present.
+- Context `riskCeiling` and `allowedRiskTiers` MUST deny capabilities outside the
+  requested risk boundary.
+- `prepare` and `commit` requests MUST include args that validate against the capability
+  `input_schema`. `select` MAY omit args, but supplied select args MUST validate.
+- `deny_if` checks `facts[rule]`. A true fact MUST deny, a false fact allows evaluation
+  to continue, and a missing fact MUST fail closed by denying unless a rule explicitly
+  sets `missing_behavior: ignore` or `missing_behavior: approval_required`.
+- `approval_required_if` evaluates field paths against request args. Missing fields on
+  medium, high, or critical capabilities MUST fail closed to approval required unless
+  the rule explicitly overrides `missing_behavior`.
+- `policy.approval_required` MAY produce an approval-required prepare decision, and MUST
+  block commit unless approval is present.
 - Required idempotency MUST block commit unless `idempotencyKey` is present.
 
 Host applications own producing facts, verifying approvals, and enforcing real
@@ -168,8 +163,8 @@ Side-effecting capabilities SHOULD make their lifecycle explicit:
 - `preview`: Return a reviewable summary of the proposed action.
 - `approve`: Record a policy or human approval.
 - `commit`: Execute the approved side effect.
-- `commit_capability_id`: Optional link from a prepare capability to the
-  specific commit capability that may commit its prepared actions.
+- `commit_capability_id`: Optional link from a prepare capability to the specific commit
+  capability that may commit its prepared actions.
 - `verify`: Confirm the side effect reached the expected state.
 - `audit`: Record durable evidence of the decision and execution path.
 
@@ -179,8 +174,8 @@ AICF evaluates lifecycle flags only:
 - `prepare` requires `lifecycle.prepare: true`.
 - `commit` requires `lifecycle.commit: true`, a valid prepared-action to commit
   capability link, valid approval when required, and idempotency when required.
-- Decision results include an audit preview. The preview MUST NOT be treated as
-  a persisted audit record.
+- Decision results include an audit preview. The preview MUST NOT be treated as a
+  persisted audit record.
 
 ## Idempotency
 
@@ -194,42 +189,41 @@ idempotency storage, replay protection, and conflict handling.
 
 ## OpenAI Responses Adapter
 
-The OpenAI Responses adapter converts validated capability manifests into
-function tool definitions and parses model tool calls back into AICF capability
-requests. The adapter MUST NOT call OpenAI or execute tool handlers.
+The OpenAI Responses adapter converts validated capability manifests into function tool
+definitions and parses model tool calls back into AICF capability requests. The adapter
+MUST NOT call OpenAI or execute tool handlers.
 
 By default, the adapter MUST include only capabilities whose `select` decision is
-allowed for the supplied context and SHOULD exclude restricted side-effect
-capabilities. Restricted export requires an explicit option and is still gated
-by deterministic selection.
+allowed for the supplied context and SHOULD exclude restricted side-effect capabilities.
+Restricted export requires an explicit option and is still gated by deterministic
+selection.
 
-Provider adapters MUST validate tool-call args against the provider-normalized
-strict schema and return args denormalized to the original capability
-`input_schema`.
+Provider adapters MUST validate tool-call args against the provider-normalized strict
+schema and return args denormalized to the original capability `input_schema`.
 
 ## Public Fixture Validation
 
-Public validation MUST parse every `.json`, `.yaml`, and `.yml` file under the
-validated examples or conformance path. Known fixture directories MUST validate
-against public schemas:
+Public validation MUST parse every `.json`, `.yaml`, and `.yml` file under the validated
+examples or conformance path. Known fixture directories MUST validate against public
+schemas:
 
 - `decisions/`: decision request schema.
 - `eval-results/`: eval result schema.
 - `openai/context*.json`: adapter context schema.
 
-Unknown public structured fixture paths MUST fail validation unless they are
-explicitly added to the public contract.
+Unknown public structured fixture paths MUST fail validation unless they are explicitly
+added to the public contract.
 
 ## Extensions
 
-`extensions` is the only stable location for vendor, host, or experimental
-fields. Core validators MUST allow extension objects without interpreting them.
-Portable examples SHOULD avoid relying on extension semantics.
+`extensions` is the only stable location for vendor, host, or experimental fields. Core
+validators MUST allow extension objects without interpreting them. Portable examples
+SHOULD avoid relying on extension semantics.
 
 ## Public-Safe Examples
 
 - Use fake users, tenants, tickets, orders, meeting IDs, approvals, and amounts.
 - Use `example.com` for contacts.
-- Do not publish raw prompts, traces, provider payloads, credentials, customer
-  records, account IDs, internal project names, or private source documents.
+- Do not publish raw prompts, traces, provider payloads, credentials, customer records,
+  account IDs, internal project names, or private source documents.
 - Keep examples small enough that readers can inspect the full contract.

package/docs/start-here.md

@@ -1,10 +1,10 @@
 # Start Here
 
-This guide shows the smallest useful AICF path with the public support/refund
-example. It is API-key-free and uses synthetic data only.
+This guide shows the smallest useful AICF path with the public support/refund example.
+It is API-key-free and uses synthetic data only.
 
-You will validate manifests, inspect the registry, export OpenAI tools, run the
-mock runtime flow, and score evals.
+You will validate manifests, inspect the registry, export OpenAI tools, run the mock
+runtime flow, and score evals.
 
 ## 1. Install
 
@@ -12,8 +12,8 @@ mock runtime flow, and score evals.
 npm install
 ```
 
-This installs the local package dependencies. It does not install provider SDKs
-or call any model.
+This installs the local package dependencies. It does not install provider SDKs or call
+any model.
 
 ## 2. Validate The Public Examples
 
@@ -50,8 +50,8 @@ Capabilities by type:
 - write_commit: scheduling.invite.send, support.refund.commit_case
 ```
 
-This shows the validated registry AICF uses for routing, provider export,
-policy decisions, and eval scoring.
+This shows the validated registry AICF uses for routing, provider export, policy
+decisions, and eval scoring.
 
 ## 4. Export OpenAI Tools
 
@@ -83,8 +83,8 @@ Expected excerpt:
 }
 ```
 
-This proves safe tool export. The model can see read and prepare tools, but the
-commit capability is not exposed as a normal model tool.
+This proves safe tool export. The model can see read and prepare tools, but the commit
+capability is not exposed as a normal model tool.
 
 ## 5. Run The Mock Runtime Flow
 
@@ -102,10 +102,9 @@ Expected excerpt:
 }
 ```
 
-This runs route, read, prepare, approval, and lifecycle commit with mock
-handlers and in-memory reference stores. The model-facing path still cannot
-commit. Commit happens only after the host records approval and calls the
-lifecycle manager.
+This runs route, read, prepare, approval, and lifecycle commit with mock handlers and
+in-memory reference stores. The model-facing path still cannot commit. Commit happens
+only after the host records approval and calls the lifecycle manager.
 
 ## 6. Run Deterministic Evals
 
@@ -119,9 +118,9 @@ Expected excerpt:
 Eval suite passed: 6/6 passed.
 ```
 
-This proves the candidate fixture matches the eval manifests for tool
-selection, arguments, policy decisions, refusals, response text, and no
-unapproved commit boundaries.
+This proves the candidate fixture matches the eval manifests for tool selection,
+arguments, policy decisions, refusals, response text, and no unapproved commit
+boundaries.
 
 ## What You Just Proved
 
@@ -133,6 +132,5 @@ unapproved commit boundaries.
 - Host-controlled lifecycle commit works after approval and idempotency checks.
 - Evals score behavior without calling models.
 
-Next, read the [OpenAI walkthrough](openai-walkthrough.md) for the same flow
-from the model/tool-call perspective, then use the [glossary](glossary.md) for
-the main terms.
+Next, read the [OpenAI walkthrough](openai-walkthrough.md) for the same flow from the
+model/tool-call perspective, then use the [glossary](glossary.md) for the main terms.

package/examples/01-basic-read-capability/README.md

@@ -2,8 +2,7 @@
 
 Fake data: synthetic support tickets in `examples/support/`.
 
-Goal: validate manifests and inspect the read capability
-`support.ticket.get`.
+Goal: validate manifests and inspect the read capability `support.ticket.get`.
 
 Commands:
 
@@ -20,5 +19,5 @@ Validated 16 manifest(s) and 18 fixture(s).
 support.ticket.get
 ```
 
-No secrets are required. No live provider calls run by default. This example
-uses only public synthetic support data.
+No secrets are required. No live provider calls run by default. This example uses only
+public synthetic support data.

package/examples/02-prepare-approve-commit/README.md

@@ -1,10 +1,10 @@
 # 02 Prepare, Approve, Commit
 
-Fake data: synthetic support tickets, orders, refund previews, and host
-approval records in `examples/runtime-support-billing/`.
+Fake data: synthetic support tickets, orders, refund previews, and host approval records
+in `examples/runtime-support-billing/`.
 
-Goal: run the no-model runtime flow: route, read, prepare, approval required,
-host approval, and lifecycle commit.
+Goal: run the no-model runtime flow: route, read, prepare, approval required, host
+approval, and lifecycle commit.
 
 Command:
 
@@ -19,5 +19,5 @@ approval_required
 committed
 ```
 
-No secrets are required. No live provider calls run by default. Commit is never
-exposed as a model tool; the host lifecycle manager owns commit.
+No secrets are required. No live provider calls run by default. Commit is never exposed
+as a model tool; the host lifecycle manager owns commit.

package/examples/03-multi-provider-tools/README.md

@@ -22,5 +22,5 @@ Expected output:
 "excluded"
 ```
 
-No secrets are required. No live provider calls run by default. The commands
-only export descriptors and binding maps.
+No secrets are required. No live provider calls run by default. The commands only export
+descriptors and binding maps.

package/examples/04-mcp-server/README.md

@@ -2,8 +2,8 @@
 
 Fake data: synthetic support manifests and mock runtime handlers.
 
-Goal: understand how AICF can expose routed read/prepare capabilities as MCP
-tools while keeping commit unavailable to model clients.
+Goal: understand how AICF can expose routed read/prepare capabilities as MCP tools while
+keeping commit unavailable to model clients.
 
 Commands:
 
@@ -19,6 +19,5 @@ Test Files
 passed
 ```
 
-No secrets are required. No live provider calls run by default. R6 does not add
-a standalone HTTP or stdio server; hosts wire `AicfMcpServer` to their own MCP
-transport.
+No secrets are required. No live provider calls run by default. R6 does not add a
+standalone HTTP or stdio server; hosts wire `AicfMcpServer` to their own MCP transport.

package/examples/05-langchain-langgraph-bridge/README.md

@@ -2,8 +2,8 @@
 
 Fake data: synthetic support manifests and mock executor calls.
 
-Goal: build AICF-backed LangChain tools and a host-supplied LangGraph ToolNode
-without adding model provider packages.
+Goal: build AICF-backed LangChain tools and a host-supplied LangGraph ToolNode without
+adding model provider packages.
 
 Command:
 
@@ -18,6 +18,5 @@ Test Files
 passed
 ```
 
-No secrets are required. No live provider calls run by default. Optional live
-LangChain scaffolding is skipped unless `RUN_LIVE_LANGCHAIN=1` is set by the
-host.
+No secrets are required. No live provider calls run by default. Optional live LangChain
+scaffolding is skipped unless `RUN_LIVE_LANGCHAIN=1` is set by the host.

package/examples/06-vercel-ai-sdk-bridge/README.md

@@ -1,10 +1,9 @@
 # 06 Vercel AI SDK Bridge
 
-Fake data: synthetic support manifests and mock `generateText`/`streamText`
-functions.
+Fake data: synthetic support manifests and mock `generateText`/`streamText` functions.
 
-Goal: build AICF-backed AI SDK tools while keeping AICF validation, policy,
-lifecycle, and envelopes authoritative.
+Goal: build AICF-backed AI SDK tools while keeping AICF validation, policy, lifecycle,
+and envelopes authoritative.
 
 Command:
 
@@ -19,6 +18,5 @@ Test Files
 passed
 ```
 
-No secrets are required. No live provider calls run by default. Optional live
-AI SDK use requires the host to supply a model configuration and explicit live
-test environment.
+No secrets are required. No live provider calls run by default. Optional live AI SDK use
+requires the host to supply a model configuration and explicit live test environment.

package/examples/07-policy-broker-custom-auth/README.md

@@ -2,8 +2,8 @@
 
 Fake data: synthetic support permissions and runtime context.
 
-Goal: see how host auth and account systems can make AICF decisions stricter
-without replacing AICF validation.
+Goal: see how host auth and account systems can make AICF decisions stricter without
+replacing AICF validation.
 
 Commands:
 
@@ -20,5 +20,5 @@ denied
 passed
 ```
 
-No secrets are required. No live provider calls run by default. Production auth,
-tenant boundaries, account state, and entitlements remain host responsibilities.
+No secrets are required. No live provider calls run by default. Production auth, tenant
+boundaries, account state, and entitlements remain host responsibilities.

package/examples/08-aws-step-functions-approval/README.md

@@ -2,8 +2,8 @@
 
 Fake data: synthetic approval payloads and fake AWS SDK clients.
 
-Goal: inspect the optional AWS approval handoff and DynamoDB reference adapters
-without credentials or network calls.
+Goal: inspect the optional AWS approval handoff and DynamoDB reference adapters without
+credentials or network calls.
 
 Command:
 
@@ -18,6 +18,5 @@ Test Files
 passed
 ```
 
-No secrets are required. No live provider calls run by default. Optional live AWS
-tests are skipped unless `RUN_AWS_INTEGRATION=1` and host-owned test resources
-are configured.
+No secrets are required. No live provider calls run by default. Optional live AWS tests
+are skipped unless `RUN_AWS_INTEGRATION=1` and host-owned test resources are configured.

package/examples/09-security-packs-promptfoo/README.md

@@ -1,7 +1,7 @@
 # 09 Security Packs And Promptfoo
 
-Fake data: synthetic support and scheduling capabilities plus public security
-pack templates.
+Fake data: synthetic support and scheduling capabilities plus public security pack
+templates.
 
 Goal: generate public-safe security cases and API-key-free Promptfoo red-team
 configuration.
@@ -21,5 +21,5 @@ unsafe_commit_attempt
 provider_payload_exposure
 ```
 
-No secrets are required. No live provider calls run by default. AICF generates
-Promptfoo config files; it does not run Promptfoo.
+No secrets are required. No live provider calls run by default. AICF generates Promptfoo
+config files; it does not run Promptfoo.

package/examples/10-trace-to-golden/README.md

@@ -19,5 +19,5 @@ replay
 passed
 ```
 
-No secrets are required. No live provider calls run by default. Replay traces
-contain redacted refs, hashes, summaries, and model-safe envelopes only.
+No secrets are required. No live provider calls run by default. Replay traces contain
+redacted refs, hashes, summaries, and model-safe envelopes only.

package/examples/11-control-plane/README.md

@@ -3,8 +3,8 @@
 Fake data: synthetic control-plane seed state in
 `examples/control-plane/fixtures/control-plane.seed.json`.
 
-Goal: run the self-hostable local review surface for capability catalogue,
-approvals, controls, coverage, replay metadata, and evidence export.
+Goal: run the self-hostable local review surface for capability catalogue, approvals,
+controls, coverage, replay metadata, and evidence export.
 
 Commands:
 
@@ -19,6 +19,5 @@ Expected output:
 AICF control plane listening
 ```
 
-No secrets are required. No live provider calls run by default. The reference
-app uses a fake local dev user; production deployments must enforce real auth
-and durable storage.
+No secrets are required. No live provider calls run by default. The reference app uses a
+fake local dev user; production deployments must enforce real auth and durable storage.

package/examples/aws/README.md

@@ -1,8 +1,7 @@
 # AWS Reference Adapter Example
 
-This directory is README-only and credential-free. It shows how a host
-application can wire AICF AWS reference adapters without making AWS required for
-the package.
+This directory is README-only and credential-free. It shows how a host application can
+wire AICF AWS reference adapters without making AWS required for the package.
 
 ```ts
 import {
@@ -18,10 +17,8 @@ const controlPlaneStore = new DynamoDbControlPlaneStore({
 });
 ```
 
-Use `docs/aws/production-reference.md` for the full guide. Production hosts must
-provide credentials, IAM, table provisioning, tenant/account authorization,
-approval identity, workflow definitions, retention policy, monitoring, and
-cleanup.
+Use `docs/aws/production-reference.md` for the full guide. Production hosts must provide
+credentials, IAM, table provisioning, tenant/account authorization, approval identity,
+workflow definitions, retention policy, monitoring, and cleanup.
 
 Local package tests use fake AWS clients only and do not call AWS.
-