Valdris v0.9 Semantic and Authoritative Assurance

Valdris v0.9 adds two stronger claim levels without adding a fourteenth production domain. Layer 0 remains the foundation assurance plane; orchestration, memory, model routing, agent coordination, proof execution, and interoperability remain cross-cutting concerns over the existing thirteen assurance domains.

The repository is 0.9.0-rc.1 until a commissioned target completes a real provider-backed authoritative run. The default authority trust store is intentionally empty, so this repository cannot certify itself.

Source image: Valdris trust model from structural to semantic to authoritative assurance

Claim levels

Level	What it proves	Required closure
structural	Schemas, paths, digests, local validators, review, and packet bindings are coherent.	Existing Valdris gates plus valdris.run-packet.v3.
semantic	Owner-selected thresholds and control-specific adapters prove the intended workload behavior.	Implementation readiness, signed semantic-execution results, semantic assurance, runtime session, AI-change review, and signed augmentation/threshold approvals.
authoritative	Semantic proof ran under externally trusted execution and monotonic state.	Semantic closure plus signed model-routing, trace, usage, immutable-executor, and bridge-head receipts.

Historical valdris.run-packet.v2 documents remain readable as structural evidence. They are never silently upgraded. A v3 packet snapshots canonical catalog JSON and binds each snapshot to the raw catalog bytes in its committed validation runtime, so catalog evolution does not replace historical policy. When the packet commit is not the checked-out HEAD, the gate performs an integrity-only inspection, reports the effective assurance level as structural, and preserves the original claim only as recordedAssuranceLevel. It does not run current validators or call that operation a replay. Full revalidation requires an isolated checkout at the exact reachable packet commit using that commit's validator runtime.

Canonical artifacts

Path	Contract	Purpose
run/implementation-readiness.json	uash.implementation-readiness.v1, uash.implementation-readiness-receipt.v1, and uash.implementation-start-receipt.v1	Resolves contracts and red-test evidence, seals them at one monotonic head, then separately proves the first mutation began at a later head.
assurance/semantic.json	valdris.semantic-assurance.v1	Binds additive augmentation, acceptance policy, semantic adapters, AI identity, and approvals.
runtime/session.json	valdris.runtime-session.v1	Binds connector conformance, agent DAG/fan-in, capabilities, hooks, context, memory, routing, usage, and receipts.
review/change-review.json	uash.ai-change-review.v1	Proves changed paths, diff, dependencies, lockfiles, error paths, tests, security, and observability were reviewed.
release/promotion.json	uash.promotion-receipt.v1	Prevents prototype evidence from being relabeled as production proof.
learning/feedback-loop.json	uash.harness-learning.v1	Closes failure to RCA to regression to reviewed harness change, expiry, and rollback.
assurance/authoritative.json	valdris.authoritative-closure.v1	Binds the applicable artifacts, claim level, and catalog snapshots.
run/packet.json	valdris.run-packet.v3	Freezes all inputs, gates, catalogs, review provenance, assurance level, and evidence inventory.

The canonical closure files above bind the following operating-contract artifacts rather than accepting embedded prose or passed: true flags:

Path	Contract	Enforcement
run/requirements-contract.json	uash.requirements-contract.v1	Maps each requirement to acceptance criteria, sealed red tests, commissioned eval suites, and goal stopping conditions.
run/acceptance-results.json	uash.acceptance-results.v1	Proves every mapped acceptance test and eval suite finished green with digest-bound evidence after implementation.
runtime/tool-registry.json	valdris.tool-registry.v1	Versions tool schemas, effects, risk, approval, timeout, retry, audit, and least-privilege scopes; runtime/session.json records observed calls.
runtime/driver.json and runtime/driver-state.json	valdris.runtime-driver.v1 and valdris.runtime-driver-state.v1	Bind the external runtime adapter, lease, compare-and-swap checkpoint, goal/stop policy, and implementation-execution receipt.
runtime/economics.json	uash.ai-economics-ledger.v1	Reconciles provider usage, tokens, tool calls, retries, latency, model/tool spend, human review, budget, and optional tenant attribution.
runtime/decision-evidence.json	uash.decision-evidence.v1	Records observable decision alternatives, selection, rationale, authority, evidence, and outcome without private chain-of-thought.
runtime/interop/{mcp,a2a}.json	valdris.interop-transcript.v1	Proves initialization, version/schema negotiation, auth-root isolation, capability discovery, correlation, timeout, cancellation, unknown-tool rejection, and replay protection. A completed transcript also carries a separately signed valdris.interop-execution-receipt.v1.
evals/calibrations/<suite>.json	uash.model-judge-calibration.v1	Required only when an evaluator is a language model; binds independent judge identity, human labels, agreement/error limits, critical slices, and expiry.
trajectory/trajectory.json plus its JSONL trace	valdris.trace-receipt.v2	Cross-binds the evaluated trajectory artifact, exact observable trace bytes/count, redaction policy, runtime session, and decision evidence.

Trust boundary

controls/authority-trust.v1.json contains only commissioned Ed25519 public keys. Operators pin its canonical JSON digest outside the repository as VALDRIS_AUTHORITY_TRUST_SHA256. Agents cannot add a key, select a weaker threshold, lower a tier, approve their own augmentation, or turn unsigned provider output into authoritative evidence.

scripts/attested-proof-executor.mjs is the optional OCI reference executor. The human-approved valdris.acceptance-policy.v1 pre-commissions its exact command identity, semantic-validator-set digest, immutable base-image digest, executor identity, absolute Git and OCI-runtime paths, binary digests, daemon identity, and exact CPU, memory, output-byte, total wall-clock, scope, and cleanup-reserve limits; the runtime receipt must match them. Source materialization reads raw Git objects, records every tree entry and content digest, ignores export-ignore and export-subst, and rejects submodules. Git and runtime commands execute with isolated HOME/config state, no system or user configuration, the local-default runtime endpoint, and the commissioned daemon ID/version. It never bind-mounts the live worktree or an output directory: bounded /output and /tmp tmpfs mounts are owned by UID/GID 65534:65534. The operator supplies a pre-created output root whose absolute path, current UID or SID ownership, POSIX mode or Windows DACL, reparse status, and stable file identity are commissioned; npm run operator-root:inspect -- --root ABSOLUTE_PATH emits the path and identity digests used by VALDRIS_EXECUTOR_OUTPUT_ROOT_PATH_SHA256 and VALDRIS_EXECUTOR_OUTPUT_ROOT_IDENTITY_SHA256. Each execution reserves exactly one direct child and rechecks both identities before accepting output. Execution inherits no ambient secrets, disables network by default, applies CPU/memory/PID/file limits, drops capabilities, and enables no-new-privileges. limits.wallClockMs is one total host-operation deadline covering preflight, raw-object materialization, import, build, inspection, container execution, output materialization, cleanup, and the final output-root identity check; completedOperationElapsedMs and finishedAt are measured only after that last check. The validator recomputes receipt elapsed time, enforces that scope, bounds the cleanup reserve, and rejects any limit or duration substitution. A per-execution cidfile and unique container name bind cleanup to one run, and cleanup succeeds only after runtime inspection confirms both identities are absent. The container emits a bounded valdris.proof-executor-output.v1 envelope containing canonical semantic-proof, proof-input, and accepted-gate manifests; Valdris validates their bytes, materializes the artifacts, recomputes every set digest, and only then signs the executor receipt. Networked proof requires a separately commissioned allowlist adapter.

scripts/github-bridge-head.mjs is the currently executable authoritative adapter for the provider-neutral valdris.bridge-head-receipt.v1 core. The acceptance policy commissions the provider identity, adapter schema, canonical GitHub hostname, exact target digest, secure receipt-root identity, and complete protection policy. Every GitHub API call supplies that hostname explicitly; ambient GH_HOST is removed. The GitHub policy must enforce admins, linear history, strict status checks from the commissioned append-only validator GitHub App, and exact app-only writer restrictions; force pushes and branch deletion remain disabled. Writer restrictions bind each GitHub App's numeric ID and slug, and the append-only validator App ID must be distinct from every writer App ID so the writer cannot self-approve a rollback. The proposal policy fixes rebase as the only merge method, one total operation deadline, polling cadence, and the full-history replay interval. The remaining deadline is passed to every CLI subprocess, and success observed after expiry is rejected. Branch protection is revalidated before proposal, before merge, and after merge, with all observations bound into the provider proof. The core receipt remains provider-neutral, but authoritative validation rejects non-GitHub provider proofs until a reviewed executable provider-validator interface and implementation are added; signed JSON shape alone is not sufficient.

The adapter derives a deterministic operation identity and record timestamp from the immutable request, then checks an explicit expected sequence, head, and cumulative history digest. Normal verification reads one authenticated checkpoint and its immutable tail, so history depth does not increase provider-call count. At each commissioned interval, the separate status-check App must attest a full replay through the proposed sequence; its machine-readable attestation binds operation, head, cumulative digest, protection evidence, and replay result. The adapter creates a proposal branch, appends the zero-padded record, updates the cumulative checkpoint, and opens a pull request. Immediately before merge it verifies that the protected base has not advanced, then requests a protected rebase merge while supplying the expected proposal SHA. It never writes directly to the protected branch or bypasses branch protection.

After merge, the adapter requires the protected ref, checkpoint, immutable tail, content identity, pull-request evidence, commissioned check, and protection observations to agree exactly. If the process crashes after merge, rerunning the same deterministic operation reconciles that durable state instead of creating a second append. Cleanup failure is recorded after a committed merge and retried on resume. Before any provider mutation, signer/trust material is loaded and a receipt filename is exclusively reserved under a pre-created operator-controlled root. That root must be outside repository ancestors, owned by the current UID or SID, restrictive under POSIX mode or Windows DACL rules, free of escaping symlinks/reparse points, and stable in path and file identity through receipt commit. The signed receipt binds hostname, repository, branch, operation, explicit history CAS, cumulative checkpoint, pull request, commissioned check and replay attestation, merge, cleanup result, three-phase protection observations, root identity, and subject. The adapter does not run automatically and requires the commissioned protected branch plus an operator-controlled signing key.

Model, context, and agent runtime

AI claims bind model, provider, prompt, tools, corpus, memory policy, eval plan, smoke test, and observability policy in uash.ai-workload-identity.v1. Runtime model selection and its signed receipt must match that identity, the minimum-capability policy, the quality suite, and the recorded fallback decision. Live provider telemetry remains a commissioned adapter responsibility.

Semantic and authoritative runs require uash.context-manifest.v2: every loaded file declares kind, static or dynamic loading, purpose, owner, version, token estimate, and a trigger when dynamic. Runtime counts must exactly reconcile with the signed manifest budget. Memory events declare owner, isolation scope, content digest, lifecycle action, and expiry for writes or updates. valdris.memory-head-receipt.v1 advances a provider/store-bound head across sessions, rejects stale reads and cross-tenant ownership changes, and is externally attested for authoritative claims.

Multi-agent execution declares single-agent, orchestrator, conductor, or hybrid mode; unique agents and parents; a cycle-free DAG whose maximum width obeys the parallelism ceiling; and parent-bound joined child input/output receipts. Every tool call must resolve a registered tool, an agent capability grant, exact before/after hook receipts, and—when consequential—a signed, time-bound human approval. Connector, hook, context, memory, and optional MCP/A2A conformance is covered by a signed valdris.runtime-conformance-receipt.v1; npm run interop:conformance provides the bounded reference runner. The runner issues a distinct typed challenge and validates an exact request-bound response for initialization, version/schema negotiation, auth-root isolation, capability discovery, correlation, deadlines, cancellation, unknown tools, and replay. An adapter that merely echoes the test ID and passed status is rejected. Runner output alone is pending evidence: a separately trusted execution authority must sign valdris.interop-execution-receipt.v1, binding the exact adapter command and source, trusted runner digest, executor identity, auth root, timeout, transcript bytes, and request/response/assertion digest sets. The runtime commissions distinct executor and authority principals; their actor and key identities must differ, and the receipt signer must match the commissioned authority. The executing agent cannot self-attest this receipt.

The closure binds eval result, trajectory, and smoke artifacts to the commissioned uash.agent-eval-plan.v1 suite IDs and dimensions. Before the authoritative closure is authored, run-create.mjs --print-accepted-gate-set emits the digest of all pre-closure gates. The proof executor and final closure must bind that digest, and the final packet recomputes it.

uash.ai-change-review.v1 must start at the pre-implementation Git fixed point sealed into readiness. The validator proves that base is also the merge base, derives the binary diff, exact changed paths, changed lockfiles, and the dependency delta encoded by npm, pnpm, Yarn, Cargo, uv, Poetry, Go, or pinned requirements lockfiles instead of accepting an agent-authored summary. Added or updated dependencies require valdris.dependency-provenance.v1, including registry/source, publisher, license, content/integrity/vulnerability/provider receipts, allowlist approval, and a passed confusable-name check. Unknown lockfile formats fail closed.

Valdris remains the control plane, not the coding runtime. Codex, Claude Code, Hermes, or a commissioned custom adapter performs implementation. scripts/runtime-driver-state.mjs is the provider-neutral reference for durable lease/checkpoint/stop-state transitions; valdris.implementation-execution-receipt.v1 binds what that runtime actually changed under the commissioned sandbox and capability policy.

Release rule

Do not tag v0.9.0 from mocked receipts, local-executor evidence, or the harness verifier. 0.9.0-rc.1 remains the local validation milestone. A stable tag must exactly equal v plus the candidate version read from the resolved HEAD:package.json, so mutable worktree metadata cannot authorize a release and v0.9.0 cannot be issued from this prerelease commit. The candidate HEAD, local pre-release tag target, closure commit, executor sourceCommit, and applicable promotion commit must be identical, while the bridge-head receipt must bind the same run and proof closure. Once the committed candidate version is 0.9.0, npm run release:gate:authoritative -- --tag v0.9.0 --repository-root ABSOLUTE_VERIFIED_CANDIDATE_CHECKOUT --run-root ABSOLUTE_RUN_ROOT still fails closed unless an authorized target has a valid commissioned OCI executor receipt and provider-backed rollback-resistant head. The explicit repository root prevents the protected validator checkout's version from being substituted for the separately verified candidate. Stable tags are created only by the protected, manual .github/workflows/authoritative-release.yml path after it verifies a trusted same-repository workflow run, exact artifact provenance, intended commit, operator-held trust, real provider execution, and the dedicated release-App identity. A tag-push workflow is not the control because it runs after the ref already exists. Complete Authoritative Release Commissioning, including the stable-tag ruleset, before enabling the workflow. Until then, report structural or semantic status precisely and keep missing external proof open.

Verification

npm run catalog:gate
npm run schema:compat:gate
npm run operating-contract:gate -- --file run/requirements-contract.json
npm run interop:conformance -- --help
npm run verify:v09-assurance
npm run verify:attested-executor
npm run verify:authoritative-release
npm run verify:authoritative-release-workflow
npm run release:gate:authoritative
npm run verify:run-packet-trust
npm run verify:harness
npm run assurance:readiness -- --level authoritative