capabilities.md

title	Capabilities
description	The full capability list behind the README summary: deterministic scheduling, lineage, replay, audit chain, receipts, and the reachability notes that scope each claim.

Capabilities

The README keeps a four-line summary; this page is the full list. The exhaustive, row-per-capability index is the feature matrix, and recent additions land in what's new.

The through-line is the verifiability surface: an always-on lineage spine and replay journal, an opt-in HMAC-chained audit log, signed agent cards, an air-gap deploy profile, plus broad CLI adapter coverage.

Full capabilities

• Deterministic scheduler: zero LLM in the coordination loop. Plain Python decides who runs, where, with what budget. Replay yesterday's plan, get yesterday's task graph.

• Per-artefact lineage records every adapter file write, without per-adapter opt-in, as one Merkle-chained, HMAC-tagged entry in an always-on lineage spine (.sdd/lineage/<run_id>/spine.jsonl). The chain head hash is the run's artifact-provenance identity. CLI: bernstein lineage verify <run_id> (recompute the chain, distinct NO ENTRIES status for empty runs) and bernstein lineage replay <run_id>.

• Always-on replay journal: every run records into one Merkle-chained event journal (.sdd/runs/<run_id>/journal.jsonl) whose head hash is the run identity; no on/off flag, BERNSTEIN_REPLAY_RETENTION caps disk. Non-determinism surfaces as a hash mismatch: bernstein replay <run_id> --verify recomputes the head and reports the exact first divergent step, and bernstein replay <run_id> --from-step N rebuilds deterministic state. The journal head is sealed into the lineage spine so replay identity and artefact provenance share one root. Provider-side context mutations (server-side compaction and similar opaque state) are recorded as content-addressed journal entries, so a change to what the model actually saw surfaces as divergence at the exact step instead of drifting silently; deterministic runs request suppression and fail loudly if a mutation arrives anyway.

• HMAC-SHA256 audit chain per RFC 2104, one record per scheduling decision, tamper-evident. Enabled with --audit, BERNSTEIN_AUDIT=1, or a compliance preset; off by default. Operator guide: audit log operator guide.

• 40+ CLI agent adapters, plus a generic --prompt wrapper for anything else. Source of truth: the adapter index.

• Bearer-token task server authenticates the manager and every worker. Per-session zero-trust JWT in .sdd/runtime/agent_tokens/, legacy BERNSTEIN_AUTH_TOKEN fallback, opt-out via BERNSTEIN_AUTH_DISABLED=1. Flow + diagnostics: manager auth.

• Signed agent cards use detached JWS (RFC 7515 §A.5) over RFC 8785 (JCS) canonicalization, with Ed25519 / EdDSA keys. Code: agent_card_signer.py.

• Content credentials: a C2PA 2.2 manifest for any produced artifact is a deterministic projection of that artifact's lineage-spine subtree, signed with the install-identity key so one attestation root covers both who ran it and what was produced. Stripping the spine makes the manifest unproducible, not merely unsigned. Watermark/fingerprint soft-binding layers are pluggable. CLI: bernstein credential emit <artifact> --run-id <run_id> and bernstein credential verify <artifact>.

• Tamper-evident memory: every cross-session memory write is an append-only, HMAC-tagged chained record attributing a claim to an actor at a time (entry_hash = H(prev, source_hash, actor, claim, model, timestamp, ...)), stored per identity scope (user / agent / run / app) under .sdd/memory/chain/<scope>/<namespace>.jsonl and anchored to the lineage spine that produced it. Forgetting appends a signed tombstone rather than deleting, so the original stays provable. CLI: bernstein memory verify --scope <s> --namespace <ns> (proves a fact was written by the claimed actor and never edited), bernstein memory why <fact> ... (returns the originating run and step), and bernstein memory forget <entry_hash> ....

• Compaction receipts: every context compaction of a long-running worker is validated mechanically (code blocks and error text must survive) and recorded as an HMAC-chained receipt. CLI: bernstein compaction log --task <id>. Operator guide: context compaction.

• Cost-aware scheduling (USD budgets, pools, batch and cache policies): USD ceilings per task / run / day are enforced before dispatch against a hash-pinned, config-overridable price table (no network lookup in the scheduling loop). Every budget decision is a pure function of (price table, spend ledger, caps), so two operators with the same ledger reproduce byte-identical decisions; a halt is a sealed receipt naming the exact policy inputs (price_table_hash, ledger_state_hash, policy_hash) and the projected overrun, anchored in the lineage spine and mirrored into the audit chain (cost.dispatch_receipt). bernstein cost policy verify <decision_hash> recomputes the decision from the stored bytes and re-checks the spine anchor offline; a forged admit or zeroed overrun fails like a tampered chain entry. Usage is attributed to named pools (api, subscription) with independent caps, and bernstein cost policy preflight surfaces pool exhaustion before a run starts rather than mid-run. Batch dispatch and cache-window fan-out (one warm-up call primes a shared prompt prefix for M cache-hitting workers) are gated on a declared adapter capability map -- refused, never faked, on an adapter without the surface, and cache windows default off. bernstein doctor flags a stale price table.

• Signed OTel span projection: the OpenTelemetry GenAI export is a deterministic projection of the run event journal rather than random-id telemetry. Every span id is derived from the journal entry hash it projects, each span carries bernstein.journal.entry_hash, and the whole span set is signed with the install identity. Two replays export a byte-identical trace, a tampered span breaks the entry-hash binding, and the local JSONL store emits even with no OTLP endpoint set. CLI: bernstein trace project <run_id> and bernstein trace verify-projection <run_id>.

• Live OTLP streaming of journal-anchored spans: with BERNSTEIN_OTEL_ENDPOINT set, runs stream that same journal projection to any stock OpenTelemetry collector as journal entries append -- live spans carry the identical journal-derived ids and bernstein.journal.entry_hash / bernstein.audit.anchor attributes, so a live trace and a replayed projection are literally the same spans, and each run's export is bound to the audit chain via an otel.projection event. Off by default: no endpoint means no exporter initialisation and no network attempts. Backfill a completed run with bernstein telemetry export-otel --run <run_id>. Operator guide: OTLP export.

• Verifiable spending mandates: when an agent spends against an external service, the signed intent, the tool calls it authorized, and the settlement reference become one journal-anchored consent receipt binding {mandate_hash, authorized_tool_calls_hash, settlement_ref, journal_entry_hash}, so "this payment was authorized by this exact intent" is provable offline. AP2-style Intent and Cart mandates are signed and revocable; per-task spend caps are enforced by the cost ledger and a cap breach is refused; revocation appends a signed entry so subsequent actions are refused. The authorized action set is a deterministic projection of (mandate, state, time), and the HTTP 402 pay-and-retry settlement (x402 / AP2 shapes) is bound into the receipt so decision-to-pay and settlement cross-verify. CLI: bernstein mandate emit, bernstein mandate verify <mandate_hash> (proves the action was authorized by the recorded intent), and bernstein mandate revoke <mandate_hash>.

• Signed payment mandates with chain-anchored receipts: outbound value transfer sits between the LLM spend ledger and the merge-approval gate, so an agent-initiated charge previously had no signed, bounded, provable authorization. A SpendMandate is an Ed25519-signed, sha256-content-addressed authorization binding an amount cap, a currency, an opaque recipient, and an expiry, issued in one of two presence modes: human_present binds a concrete transaction envelope (exact amount + recipient) the operator signed off in the loop, while delegated binds a bounded envelope (caps + expiry, optional per-transaction cap and category set) an agent transacts under. Amounts are string-encoded integer nano-units rounded exactly once half-even and text fields must be NFC, so no float ever enters a signed payload. Every attempt is a TransactionReceipt appended to the lineage spine with a .jws sidecar and mirrored as a payment.authorized / payment.refused audit event carrying the chain digest captured at decision time; a refusal is a first-class receipt with a closed-enum reason (over_max_amount, wrong_recipient, expired, cumulative_exceeded, bad_signature, wrong_presence_mode) hash-bound to the mandate, so a denied attempt is as reconstructable as an approved one. Cumulative spend is aggregated on read under a file-lock so concurrent workers sharing one mandate can never together exceed the cap. bernstein payment-mandate verify --receipt <hash> recomputes the lineage signature and the audit-chain HMAC entirely offline and reports the bound scope; tampering with the receipt body, the mandate scope, or the chain digest fails verification. Interop is scheme-agnostic through a MandateAdapter protocol (bernstein-native + generic JWS pass-through); Bernstein authorizes and proves, it never moves money. CLI: bernstein payment-mandate issue, bernstein payment-mandate show <hash>, bernstein payment-mandate spend, bernstein payment-mandate verify.

• Journal-anchored native subagent delegation: the deterministic scheduler keeps the coordination plan and delegates each leaf's mechanical execution to a native subagent (Claude Code, Codex) with per-agent model / effort / tools / background / batch settings. Each native structured result is schema-validated at the worker boundary (hallucinated keys and missing fields rejected) and anchored into the run event journal as a subagent.delegation entry carrying a replay-invariant node hash plus the result content hash. The outer DAG is a pure function of the plan, so it replays byte-identically even when inner execution is stochastic; non-interactive fan-out runs on the batch tier and its discount plus prompt-cache reads are attributed in the spend ledger.

• Stateless MCP core: the open stateless MCP protocol drops the initialize handshake and Mcp-Session-Id, so any request can land on any server instance and the protocol no longer provides cross-call ordering. Bernstein carries client capabilities in a per-request _meta field, emits W3C Trace Context (traceparent/tracestate/baggage) whose span id is derived from the call's content hash and trace id from the run root hash (two replays emit byte-identical _meta), and resolves the deprecated Sampling in-orchestrator with no LLM callback into the client. An InputRequiredResult retry base64-encodes its requestState so a different server instance resumes with no shared session memory. Each call is an ordered entry in the run event journal with its content-derived span id and is anchored into the HMAC audit chain, so cross-call continuity is chain-anchored rather than session-anchored; a cache hit references the content hash of the run that produced it. Deprecated Roots/Sampling/Logging stay behind a 12-month compatibility shim.

• Attested PR review receipts: a review run emits one signed receipt binding the issue body, the plan, the run journal head (every executed tool call), and the diff into {issue_hash, plan_hash, journal_head, diff_hash, findings, verdict}, signed with the install's Ed25519 identity and anchored in the review lineage spine, so "this PR was reviewed against this ticket without operator override" is provable offline. bernstein review-receipt verify --pr <url> recomputes issue_hash and diff_hash from the PR inputs and checks the signature and spine anchor; a tampered diff fails because diff_hash no longer matches. Autofix runs a reviewer finding's fix in an isolated git worktree, runs the gate, and emits a second receipt linking finding to fix-commit to test-result. The tracker comment is a projection of the receipt (short verdict + verify command), never the receipt body.

• Verifiable governance (RBAC, budgets, seats): for teams, every access check, budget check, and per-seat attribution is a deterministic projection over the signed lineage spine rather than mutable, separately-logged database state. Each decision is a signed, anchored record binding {subject, action, verdict, inputs_hash, journal_entry_hash}: a denied action writes a signed deny record and a budget breach a signed refuse that blocks the action. IDP groups map to roles via signed role bindings, and per-profile spend caps are enforced against per-subject spend recomputed from the cost ledger (never a stored counter). bernstein governance verify <run> re-resolves and re-projects every recorded access and budget decision from the presented bindings and ledger and confirms the recorded verdicts; a tampered verdict, a widened permission binding, or a diverged ledger fails the check. Two replays of a governance-gated run produce byte-identical decision records.

• Audited webhook node: drop Bernstein into a no-code builder or event bus as the one node that leaves a verifiable record. An inbound webhook is verified per Standard Webhooks (webhook-id / webhook-timestamp / webhook-signature), then writes a signed receipt binding {event_hash, source, journal_root} and seeds a run journal whose root references the event hash; on completion the outbound webhook carries a signed receipt binding {result_hash, journal_head}, so the returned result is provably the projection of the executed run. Retry/backoff replays the same inbound event idempotently without spawning a duplicate run, and an invalid inbound signature is rejected before anything is written. bernstein webhook verify <event_id> recomputes the inbound event hash and the outbound result hash against the journal, re-checks both Ed25519 signatures offline, and re-anchors both receipts against the webhook-node lineage spine; a tampered receipt, spine, or journal fails.

• Journal-anchored stall escalation receipts: when a worker stalls, it leaves a signed receipt that fixes the exact failure window by binding the last N entries of the run's canonical event journal by their Merkle hash, references an f03 fork point for resume, and recommends a deterministic action (resume / escalate / park). bernstein escalation verify <id> reconstructs the same trailing window from the journal, walks the journal's Merkle chain, and confirms every bound entry hash matches; tamper one journal entry inside the window and the reconstruction diverges. The receipt reconstructs offline from the journal alone, so an operator can hand it to a postmortem and get cryptographic certainty about exactly what happened before the stall. The TUI/web supervisor surfaces the receipt as a projection (stall reason, recommended action, resume fork point, spine anchor), never the signature or raw window hashes.

• Intent capsules with deterministic drift escalation: approving an unattended run approved a sentence, not a contract. At approval time the goal is compiled into an intent capsule (allowed action classes, file-scope globs, permitted adapters, egress classes, a cost-envelope reference, and an expiry) that is written to the HMAC audit chain as an intent.capsule event and bound into the run journal, so every step is attributable to one approved capsule (the goal is bound by digest, never stored verbatim). A deterministic drift monitor maps observed journal events to action classes and compares them against the capsule; the conformance verdict is a pure function of (journal, capsule), so two verifiers recompute byte-identical verdicts offline and no model runs on the drift-decision path. On divergence it emits a signed escalation receipt reusing the stall escalation shape, binding the capsule hash and the divergent events, that passes bernstein escalation verify. bernstein intent verify <task-id> recomputes conformance offline: it checks the capsule hash against the audit chain, walks the run journal Merkle chain, and maps action classes against the capsule; a tampered capsule or a reordered journal fails with no live process required. Rollout defaults to warn-only.

• Input contracts: projection-hashed params, signed refusal receipts, and a chain-anchored context capsule: the run boundary was contract enforced only on the worker's output. Now the input side is closed too. A recurring schedule declares a typed params block next to its cron and goal; at fire time the supervisor validates and coerces the values and folds the validated map's content hash into build_projection, so the params hash lands inside projection_hash and the task-id seed following the trigger_input_hash precedent -- two operators with equal schedule state and params provably fire the byte-identical task graph, and a changed param provably changes the graph hash (a params-less fire stays byte-identical to before). A value that fails its declared contract at any input boundary (schedule fire, recipes run, MCP bernstein_run / bernstein_scenario, task claim) produces a signed InputRefusalReceipt instead of a bare exit: the JSONPath of the offending field, the declared schema hash, and a digest of the rejected value (raw bytes never stored), Ed25519-signed with the install identity and anchored in the HMAC audit chain as an input.refusal_receipt event -- rejection completes before any adapter process or model invocation, so a refused fire costs zero spawns and zero tokens, and the receipt verifies offline while a tampered receipt or chain entry flips verification to fail. A spawned worker reads one signed, chain-anchored answer to "what was I given": a content-addressed context capsule of task id, run id, params hash, worktree, role, budget envelope remaining, dependency state, and the audit chain head at spawn (plus the intent capsule hash when one exists), whose hash is recorded in the spawn record, the run journal, and the audit chain as a context.capsule event. bernstein context verify <task-id> re-derives the capsule offline from the journal at the recorded chain position byte-identically, so a context divergence (different params, budget, or chain head than asserted) is caught as a hash mismatch; a sanctioned mock layer is domain-separated at signing so a fixture capsule can never verify as real. CLI: bernstein context show|verify <task-id>.

• Typed activity boundary: the deterministic scheduler is validated for coding agents, and the typed activity boundary is the contract another modality has to satisfy to participate as a replayable step. Every activity that crosses it returns an ActivityResult -- {artifact, artifact_hash, evidence_set_hash, terminal_state, reason_code} -- so the scheduler keeps the agent an opaque stochastic activity behind a hash-in / hash-out contract. A research activity content-addresses every fetched page at fetch time; a browser activity records an observation hash (screenshot / DOM snapshot) per decision step; the scheduler pins the evidence_set_hash into the run event journal as one activity.result entry, so a replay reattaches byte-identical evidence and refuses on any tamper. A malformed result is rejected at the boundary with a typed refusal before anything is journaled, and the scheduler refuses to add a stage whose evidence_set_hash equals a prior stage's (no new exogenous signal), logging the refusal. Each crossing is mirrored into the HMAC audit chain carrying only hashes, never the artifact body. bernstein activity verify <run> walks the journal, recomputes each evidence_set_hash, and reattaches the content-addressed evidence. Data / ops modalities (deterministic-plan vs side-effecting split, signed input/output artifacts) build on the same substrate.

  Reachability today. The boundary, its refusals, and bernstein activity verify ship and run on every crossing. The operator-facing route to a non-coding activity does not. Every bundled adapter declares git-diff output, worktree allocation does not branch on modality, and a research or browser activity is constructed through the Python API rather than declared in a seed, plan, or backlog file. agent_kind is accepted and validated by the team manifest but no scheduler code reads it yet, so setting it does not change how a run executes. ResearchWorker needs a fetcher and a synthesiser injected by its caller, and neither ships. The browser extra is empty in this release, so a default install gets the recorded-tape driver and asking for a live driver raises a typed refusal naming the package to install. Routing non-coding tasks off the git-only paths is tracked in #2996, and declaring a task's artifact output from a seed, plan, or backlog entry in #3110.

• Callable, discoverable A2A node: an operator could point a peer orchestrator at this instance, but the peer had to trust an unsigned endpoint and take the answer on faith. Now /.well-known/agent.json serves a JWS-signed capability card (advertised tools plus the cost, redaction, and sandbox policy delegated work runs under) that a peer verifies offline against the JWK set at /.well-known/agent.json/keys before sending anything, and every inbound POST /a2a/tasks/send response carries a lineage receipt {entry_hash, content_hash, operator_hmac, head_signature, kid} anchored in the audit chain. Identity evidence and execution evidence stay separate claims: bernstein a2a verify --receipt <file> --response <file> proves the returned answer is the one the node recorded without contacting the node, and rejects a single-byte tamper of the answer, a rewritten receipt field, or a stripped signature. A2A handler state persists, so an inbound task and its receipt survive a restart. bernstein a2a publish --endpoint <url> emits registry records (A2A Agent Card and MCP Registry surfaces) that each embed the signed card and an ed25519/<fp> publisher fingerprint, so a consumer verifies the claim against the node's own key and the registry is a transport rather than an authority.

• Signed A2A message receipts: Bernstein already signs A2A capability cards, but the cross-agent task messages themselves were not attestable. Now every inbound/outbound A2A v1.0 message is a signed lineage receipt binding {message_hash, peer_card_fingerprint, task_uuid, journal_entry_hash}, signed with the install's Ed25519 identity and anchored in the message-receipt lineage spine, so a reviewer can prove a cross-agent call happened with the exact inputs claimed without trusting either agent's logs. The A2A task lifecycle (submitted / working / input-required / completed / failed / canceled) maps 1:1 to journal terminal states with reason codes, using task_uuid as the trace root. An inbound peer card is verified against its issuer domain and cross-checked against the operator's trusted-issuer set (an untrusted card is rejected), and each inbound peer task runs in its own git worktree so no two collaborations share mutable state. bernstein interop a2a verify-thread --from-thread <task-uuid> recomputes every receipt binding, re-checks each Ed25519 signature offline, verifies the spine, and re-anchors each receipt against it, proving the visible cross-agent thread equals the executed actions; a tampered receipt, spine, or journal fails.

• Verification evidence bundles: "done" was a status plus logs; the artefacts that prove a task passed died with the worktree. Now a task declares evidence producers in its spec ({name, kind, command, required} -- test command, coverage, lint, an optional screenshot/recording for web-facing work) that run at gate time. Each output is stored content-addressed under a per-blob size cap with a gc that drops blobs no live bundle references, then bound into one signed EvidenceBundle whose canonical bytes are anchored in the evidence lineage spine and mirrored into the HMAC audit chain as an evidence.bundle event -- the bundle is the receipt, not a log beside it. Required producers gate completion; an advisory producer's failure attaches a failure record without blocking. Media evidence additionally flows through the C2PA content-credentials support, so a tampered screenshot fails its hard-binding check. Deterministic producers regenerate byte-identical bundle hashes, signatures, and spine anchors on replay. bernstein evidence show <task> renders a bundle and bernstein evidence verify <task> recomputes it offline; bernstein audit verify covers bundle integrity too, so a tampered evidence file is named and fails exactly like a tampered chain entry. PRs carry an evidence-summary block linking the bundle so review happens against sealed proof rather than rerun-and-hope.

• In-process verification gates: verification used to happen only after a worker finished -- the scheduler inspected results and re-dispatched on failure, paying a full round-trip for every miss. Now a gate-capable adapter (Claude Code) enforces the same policy the moment a worker believes it is done, inside the session, before the turn ends. At spawn the task's owned_files become a write allowlist and its required evidence_producers a completion check, persisted to .sdd/runtime/hook_gate/<session>.json; the adapter injects two blocking hooks that shell out to bernstein hook-gate check. A Stop hook runs the required verification in-session and refuses to end the turn while it fails; a PreToolUse matcher refuses an out-of-scope write (realpath-contained, so a .. traversal or an in-scope symlink resolving outside the worktree is refused). Every recordable outcome -- a blocked completion or a refused write -- is sealed as an EvidenceBundle and mirrored into the HMAC audit chain, reusing the verification-evidence schema verbatim: a verifier cannot tell from the schema whether the gate fired in-process or scheduler-side. The trust model stays explicit -- in-process hooks are defence in depth and a cost optimisation; the scheduler-side gate remains authoritative and runs regardless -- so an adapter with no blocking hook surface injects nothing and degrades to that gate with no policy weakening.

• Durable work ledger (crash-safe, machine-portable resume): run state used to die with the host -- a crash mid-run was recoverable on the same machine, but an in-flight goal could not move to another box, be handed to a colleague, or survive a reimage. Now every task-graph transition (run.open, task.scheduled/started/completed/failed, run.resumed) appends to a hash-chained JSONL ledger under .sdd/runtime/ledger/<run-id>/, using the same canonical-JSON hashing contract as the per-step replay journal: each entry links its predecessor's hash, ts stays metadata, and the redaction layer scrubs every payload string before the entry is hashed, so secrets never become portable. bernstein ledger anchor <run> verifies the chain and publishes it -- chunked, with a deterministic tree identity -- to a dedicated git ref (refs/bernstein/work-ledger/<run-id>) that travels with the repo and is mirrored into the HMAC audit chain as a work_ledger.anchor event. On any clone, bernstein ledger fetch <run> + bernstein ledger resume <run> verify the chain end to end, rebuild scheduler state by deterministic replay (byte-identical projection for the same chain), and hand the in-flight frontier to the resume watcher; a crash mid-write degrades to the last verified entry, a tampered entry fails with its exact position named, and two divergent resumes of the same ledger are detected at the fork entry and refused, never silently merged. bernstein ledger gc <run> squashes anchor history so long runs do not bloat the repo. The ledger is the shared resumable-state substrate: schedulers and long-horizon runners build on it instead of inventing new state files.

• Detached run service (submit, disconnect, reattach later): a run used to be tied to the invoking terminal and one machine's uptime -- closing the laptop or losing an SSH session killed the scheduler even though all run state was recoverable, so multi-hour goals needed tmux discipline. Now bernstein run-service submit "<goal>" --task <id>... opens a run on the durable work ledger and spawns a session-detached supervisor that owns execution and survives the terminal; the daemon is a projection of the ledger, not a separate state store. bernstein run-service attach <run> reattaches from any shell and, before rendering live progress, proves the current ledger head is a forward extension of the head last seen -- that continuity proof is the reattach artefact, so an operator can prove nothing happened off the record while they were away. Every lifecycle boundary (submit, detach, reattach, daemon restart, complete) appends a signed run.lifecycle receipt to the HMAC audit chain binding the ledger head; a supervisor killed mid-run recovers the ledger tip on restart and resumes with zero lost completed tasks (a hard-kill chaos test proves it in CI), and bernstein run-service verify <run> re-checks the audit chain, the ledger chain, and every continuity boundary offline. Off-host execution ships too: bernstein run-service submit --backend ssh runs each task on another host over ssh in its own isolated remote git worktree (one branch per task), appends a signed run.ssh_task receipt binding that worktree so an offline verifier can prove per-task isolation across the ssh boundary, resumes on the ssh backend from the ledger tip with zero lost completed tasks after a kill, and resolves any injected credentials from the credential vault only (--ssh-secret ENV=PROVIDER, never the ledger or the receipts); bernstein worker remains the cluster fan-out.

• SPIFFE-compatible workload identity: operators standardizing on SPIFFE workload identity saw a Bernstein fleet as unidentified processes and had to keep a parallel identity system beside the one their platform already ran. Now the Ed25519 install identity and each agent card map onto a deterministic SPIFFE ID (spiffe://<trust-domain>/bernstein/<install>/<agent>, where <install> is a stable fingerprint of the install public key), so two operators derive the same id for the same install and agent, and a verifier re-derives it later. When a SPIRE agent is present (optional bernstein[spiffe] extra), the X.509-SVID it issues is bound to a card by a receipt: bind_svid_to_card re-derives the SPIFFE ID, refuses any SVID whose id disagrees, stamps the reference onto the card, and appends a spiffe.svid_binding event into the HMAC audit chain carrying the binding's content hash. The binding is the receipt, not a log beside it -- strip the chain and the mapping loses its meaning. bernstein spiffe id derives the id offline; bernstein spiffe verify-binding <binding.json> --install-key <pem> --trust-domain <td> --audit-dir <dir> re-derives the id from the install key and proves the card-to-SVID binding against its chained receipt, so a tampered binding fails with its content hash no longer matching. The same SVID material projects onto the existing cluster mTLS config, so the task server enforces mutual TLS through the path it already uses. Without the extra the self-contained Ed25519 path stays the default and every existing flow is unchanged.

• Tournament runs (parallel attempts, deterministic selection): for a hard task a single attempt often lands mediocre, and operators used to re-run the task by hand and eyeball diffs, leaving no trace of why one attempt won. Now a task can declare attempts: N with scripted evaluators (test pass rate, lint status, coverage delta, mutation score, an arbitrary command); the scheduler fans out N sibling attempts in isolated worktrees with byte-identical inputs, and the winner is a pure function of the evaluator outputs with a stable attempt-hash tie-break -- no model call in the decision path. The artefact the operator sees is the proof: a signed, spine-anchored TournamentReceipt that names every attempt hash, every evaluator output, every score, the winner, and the lineage edges (one chosen, the rest sibling). Each attempt is recorded as a lineage sibling, and the selection is mirrored into the HMAC audit chain as a tournament.selection event. bernstein tournament show <task> renders a receipt and bernstein tournament verify <task> recomputes it offline -- it replays the deterministic scorer over the recorded outputs, so a tampered score or a hand-picked winner diverges from the replay and fails; bernstein audit verify covers selection integrity too. Fan-out is gated on the task's existing per-ticket budget ceiling, so it aborts with a clear error before spawning when projected spend would breach the cap, never silently multiplying cost.

• Spec-to-task-graph pipeline with requirement-hash lineage: teams that write specs first had no supported path from a requirements document to a gated task graph -- operators pasted specs into the goal prompt and hoped decomposition landed, the decomposition was not reviewable before tokens were spent, and after the run nothing could answer "which requirement produced this artefact". bernstein plan compile <spec> closes that gap with a three-stage pipeline holding at most one model call: draft extracts EARS-shaped acceptance lines into a content-addressed requirement set, approve binds the requirement-set hash into the HMAC audit chain as a spec.requirement_set receipt (the plan-approval gate for the spec), and compile turns the approved set into a task graph as a pure, model-free transformation. Each task node is content-addressed over the requirement lines it implements and nothing else, so the same approved set always compiles to a byte-identical graph (graph_hash is reproducible), every node carries at least one requirement hash (so every artefact traces back to spec lines through lineage), and editing one requirement re-plans only that node while every unaffected node keeps its exact identity -- the diff is a plain set difference over content-addressed node ids. The receipt is the artefact: a verifier can prove offline that a graph was compiled from the requirement set the operator signed off on, and any post-approval edit to a requirement line breaks the chain.

• Chain-projected unified event feed: incident review used to mean grepping several parallel event vocabularies (the SSE stream, trigger events, the audit chain, the run journal) and arbitrating by timestamp. Now one canonical grammar -- (resource id, dot-delimited label, related resource ids, payload digest) -- is a deterministic projection of the HMAC audit chain, so the same on-disk chain bytes project a byte-identical feed on every host. bernstein events query --from <hmac> --to <hmac> returns a window that embeds the from/to HMAC fence-posts of the underlying chain slice, and bernstein events verify <window> checks it offline for completeness and order: deleting or reordering any event breaks the prev-hmac linkage and fails, so "what happened, in what order" settles by chain position rather than timestamps. Composable rules fold over the feed (threshold counts, absence expectations with a negative proof, sequences keyed on lineage descent, any/all/count compounds), and a rule fire mints a fire receipt on the chain before its typed action (notify, pause/resume a schedule, cancel/suspend a task, clamp a budget envelope, drain the warm pool, pin an adapter, retry a checkpoint fork) executes -- an action with no matching receipt is rejected, and the executed action is itself a chain event, so an automated intervention is as explainable in a postmortem as a human one.

• Artifact contracts (non-code deliverables): for pipelines that also produce a report, a dataset, or an ops result, a task can declare an artifact contract and complete on a signed lineage receipt instead of a git commit, verifiable offline with bernstein artifact verify. Declaring one means writing the task record directly today: artifact_spec is not a field in a seed, plan, or backlog file, and there is no CLI option for it (#3110). See artifact contract.

Retrieval and caching

Bernstein deliberately uses no neural embeddings, no vector databases, and no external embedding APIs. There are two retrieval/caching layers, both keyword/lexical:

• Codebase RAG (core/knowledge/rag.py): SQLite FTS5 with BM25 ranking and AST-aware chunking for Python files.
• Semantic cache (core/knowledge/semantic_cache.py): TF (term-frequency) cosine similarity over word counts, not learned embeddings.

If you need real semantic retrieval (vector DB, neural embeddings), wire it yourself via the retrieval role/skill in templates/; nothing in core performs vector search.

Regulatory anchors

Regulatory mappings (EU AI Act Article 12, SOC 2 CC4/CC7, DORA / NIS2, OWASP ASI06, RFC 2104/7515/8785/8037/7636/8707) live in the compliance docs. These are mappings, not certifications.