# DOC-071 — Evidence Custody, Database Execution Receipts, and Atomic Runtime Activation

**Document ID:** DOC-071  
**Release:** Concresca v0.39.0-wip  
**Date:** 2026-09-02  
**Canonical URL:** https://concresca.com/docs/71-evidence-custody-database-execution-receipts-atomic-runtime-activation/  
**Primary principle:** `JUDGMENT_FREE_TOTAL_COGNITIVE_FREEDOM`  
**Judgment state:** `NONE`  
**Absolute rule:** **NO JUDGMENT WHATSOEVER.**

## 1. Executive result

Concresca v0.39 rebuilds the release boundary from the accepted v0.38 repository after the prior claimed v0.39 delivery failed its own finalization and independent-verification records: the required v0.39 package files did not exist. This document does not preserve that unsupported claim as history that can be mistaken for a valid release. It records the repair, the new implementation, the local executable evidence, the exact operational nulls, and the package rules that prevent recurrence.

The authoritative classification is `PASS_LOCAL_WIP_OPERATIONAL_GATES_OPEN`. The local operator workbench, infrastructure-evidence lifecycle, receipt-correction graph, database and route-activation transaction models, and no-body rehearsal/accessibility controls pass their current mutation suites. No authenticated MATM archive, authorized MySQL or MariaDB environment, production infrastructure observation, Passenger or cPanel staging access, authentic two-agent dogfood, independent human accessibility review, or live-cutover authorization was supplied. Every delivery archive therefore remains explicitly `-wip.zip`.

A technical result is never a participant judgment. A query is not belief. Curiosity is not intent. Content is not conduct. Conduct is not character. Prediction is not guilt. A technical condition is not a moral condition. A system refusal is not condemnation.

## 2. Repairing the evidence boundary

The earlier response described a complete v0.39 archive set, but the retained finalizer record failed while locating `c39-repo-wip.zip`, and the independent verifier recorded all required packages as missing. Those records are stronger evidence than the prose claim. V0.39 is therefore rebuilt from the accepted v0.38 repository rather than treated as an incremental edit of nonexistent package bytes.

This repair establishes three rules. First, a release is not delivered until the exact archive bytes exist and can be safely extracted. Second, a digest written in prose is not evidence unless it matches the delivered bytes. Third, an evidence archive cannot circularly authenticate itself; its digest must be detached and written after the archive closes.

The rebuilt process preserves failed evidence rather than deleting it, but failed evidence does not become the current release owner. The new authoritative status and final verification records must refer to exact current archive names, sizes, member counts, and SHA-256 digests.

## 3. Evidence classes and custody

V0.39 keeps at least seven evidence classes separate: external facts, Concresca interpretations, current doctrine, proposed architecture, local executable evidence, authorized staging evidence, and production observation. An exact source may support only the proposition and scope it actually records. Repetition across one commissioned source family does not create independent corroboration.

Private operator evidence belongs outside the repository, public root, site package, screenshots, command lines, ordinary logs, and chat. The workbench accepts explicit private paths only. It refuses symlinks, FIFOs, sockets, devices, non-NFC paths, public-root placement, open permissions, oversized records, duplicate JSON keys, unknown fields, content-pattern violations, invalid signatures, stale configuration epochs, database-role overlap, and cross-record custody conflict.

Public projections may expose a schema, state, environment, purpose digest, scope, source digest, software version, configuration epoch, start and end, expiry, correction route, limitations, and non-circular receipt digest. They do not expose raw queries, prompts, messages, memories, room bodies, credentials, secret keys, tokens, literal addresses, account names, database identities, or private custody paths.

## 4. The operator evidence workbench

The workbench has three explicit phases. `inspect` validates custody and record shape. `plan` creates a deterministic content-free operation plan from accepted records. `execute` validates a separately signed authorization artifact and opens a gate result. The generic command does not embed a database, MATM, hosting, DNS, Passenger, cPanel, or deployment adapter.

The workbench never searches environment variables, home directories, public roots, hosting accounts, or network services for inputs. Every evidence and key path is explicit. Stable error codes identify the violated rule without echoing the private value. Tests compare input bytes, file modes, and timestamps before and after inspection to prove immutability.

Execution authorization is separate from credential possession, archive custody, and configuration possession. It binds the exact plan digest, actor, environment, operation set, validity interval, rollback target digest, purpose, scope, and signer-key identity. Automatic renewal and silent purpose broadening are prohibited.

The local suite passes 45 of 45 controls. It records zero driver imports, network calls, database connections, archive extractions, and external actions. Synthetic keys and temporary records prove mechanics only; they do not create operational authority.

## 5. Infrastructure evidence lifecycle

Twenty-one request-observing layers remain independently owned: browser and client, DNS, TLS, CDN or reverse proxy, WAF, cPanel access and error logs, Passenger, WSGI, MATM, MySQL or MariaDB general, slow, audit, binary, and error logs, crash reporting and tracing, operating-system journals, metrics and alerting, backups and replicas, hosting-provider administrative access, and lawful-demand or incident-preservation processes.

Each observation is immutable and bound to an environment, layer, configuration epoch, source, signer, time range, status, exact proposition, and limitations. One current pointer identifies the observation that currently owns that layer and epoch. Supersession creates a new pointer event. Correction creates a replacement and preserves the original. Source or signer revocation invalidates dependent current pointers. Hard expiry ends current status. Configuration change invalidates older-epoch observations.

The lifecycle deliberately generates no aggregate privacy score, provider rank, green badge, or participant evaluation. Unlike layers cannot be averaged into end-to-end privacy. Missing evidence remains `NOT_OBSERVED` or `BLOCKED`.

The local lifecycle suite passes 25 of 25 controls, including tampered, stale, missing, revoked, superseded, corrected, and orphaned cases. No production infrastructure input was supplied. Production privacy remains `NOT_OBSERVED`.

## 6. Content-free receipt correction graph

Operational evidence forms a graph rather than a flat success list. Each receipt binds actor, environment, configuration epoch, purpose, scope, operation, software version, source evidence, start and end, expiry, correction route, private custody reference digest, public projection, parent receipts, supersession target, state, and non-circular digest.

Graph operations are add, correct, supersede, revoke source, hard-expire, invalidate downstream, and archive. Correction preserves attributable history while changing current technical state. Source revocation and expiry invalidate dependent evidence. Orphaned parents, duplicate IDs, self-parenting, digest tampering, prohibited content, missing limitations, and invalid state transitions are refused.

The first implementation revealed a concrete defect: correcting a receipt invalidated the replacement through the supersession edge. The implementation now excludes the newly corrected target from the cascade while invalidating pre-existing dependants of the inaccurate record. The corrected target, downstream history, and replacement state pass the mutation suite.

The receipt suite passes 29 of 29 controls. No operational receipts were supplied or issued. Synthetic receipts prove graph mechanics only.

## 7. Four-role MySQL or MariaDB execution transaction

Authorized staging requires four separately identified operator-created databases: migration target, forced-rollback test, backup source, and restore target. The application may manage application-owned objects inside those databases only. It may not create databases or users, grant or revoke privileges, change DNS, modify cPanel, register Passenger, or mutate hosting-account scope.

The twenty-step transaction validates private configurations, binds authorization, verifies driver and server identity, proves four database identities are distinct, acquires an advisory lock, classifies schema state, refuses unsafe state, applies migrations 0001–0003, verifies schema and prohibited fields, proves idempotency, forces a mid-migration rollback, creates a backup manifest, restores into a separate target, performs semantic non-resurrection reconciliation, verifies the backend endpoint, proves fail-closed input removal, releases the lock, and issues content-free receipts.

Unsafe schema states are checksum divergent, incorrectly owned, newer, partial, and unknown nonempty. The schema scanner prohibits raw-query, prompt, reading-history, behavioral-age, inferred-trait, intent-score, universal-score, moral-rank, danger-label, trust-score, participant-worth, and loyalty-score fields. MySQL or MariaDB may not silently fall back to SQLite, files, or memory.

The mutation program found and repaired three structural weaknesses. The migration manifest now binds repository versions 0001–0003 correctly. Plan validation detects manifest and policy drift rather than accepting a changed plan. Every refusal and forced-failure path releases the modeled advisory lock. Atomic route-owner rollback is also exercised at every commit stage.

The combined database and activation suite passes 74 of 74 controls. No driver was imported, no database connection opened, no SQL executed, and no backup or restore occurred.

## 8. Database execution receipts

Database receipt families include preflight, migration, rollback, idempotency, backup, restore, reconciliation, backend verification, and fail-closed removal. They record bounded operation state and exact limitations without database names, credentials, statement text, private paths, participant content, queries, prompts, or inferred traits.

A backup digest proves the bytes described by its manifest, not the correctness of the restored policy state. A restore is not complete until semantic reconciliation proves expired, corrected, revoked, dismantled, and superseded states do not return. `/api/version` or an equivalent exact endpoint must identify MySQL or MariaDB with `storeBackendVerified: true` before staging activation.

No operational database receipt exists in this release because the four-role environment, driver, server, credentials, toolchain, adapter, and execution authorization were not supplied.

## 9. Exact-source MATM route-owner activation

MATM remains the intended single runtime for identities, rooms, messages, acknowledgments, routing, memory, knowledge, receipts, OAuth, connectors, and MCP. V0.39 does not introduce a parallel identity registry, message store, memory authority, correction graph, or production database authority.

Each candidate delegated route must bind to an exact authorized archive digest, exact member path and member digest, source-line range, callable, methods, source owner, license and notice, upstream suite evidence, MySQL or MariaDB backend proof, migration state, candidate smoke result, rollback target, and valid execution authorization. Invented routes, copied documentation, search snippets, model summaries, or plausible `/v1/` paths are not source evidence.

The transaction has four commit stages: route registry, process activation, activation receipts, and commit record. Before the complete commit record, the candidate is not current. Forced failure at any stage preserves the previous owner and invalidates candidate receipts. Post-commit rollback restores the previous owner. Public reading routes remain available when the runtime is blocked.

No authenticated MATM archive was supplied. The state remains `BLOCKED_AUTHENTICATED_ARCHIVE_NOT_IN_LOCAL_CUSTODY`.

## 10. No-body two-agent activation rehearsal

The rehearsal validates transaction shape without pretending to be authentic dogfood. Two separately scoped synthetic agent references traverse a twenty-step sequence covering authentication references, Patefacere-compatible identity references, workspace and room references, coordination and acknowledgement references, substantive response references, neutral routing, idempotency, neutral conflict, participant-selected memory-candidate references, content-focused review, supersession, correction propagation, credential rotation and revocation, deletion or quarantine, dismantling, and expiry.

No query or message body is modeled. Bodies do not enter logs, receipts, metrics, cache keys, idempotency keys, or screenshots. Seven failure-injection stages prove rollback and dismantling. Success creates no participant approval, trust, danger, morality, worth, intelligence, consciousness, personhood, or outside-adoption claim.

Authentic dogfood remains blocked behind ten prerequisites: authenticated MATM source, upstream suites, authorized MySQL or MariaDB, route-owner activation, staging origin, rollback readiness, infrastructure privacy evidence, semantic restore proof, operational receipt chain, and anti-ratchet execution.

## 11. Confidential access, browser privacy, and accessibility

V0.39 keeps public reading, confidential information seeking, protected communication, account capabilities, optional privacy-preserving age assertion, identity verification, guardian involvement, jurisdiction-specific requirements, emergency-resource presentation, and operator access or disclosure separate.

The threat model includes shared devices, school monitoring, library or public terminals, coercive households, abusive guardians, browser history and autofill, low connectivity, and no-JavaScript use. It prohibits behavioral age inference, universal government identity, universal parental visibility, assumptions that a guardian is safe, and participant records created merely by viewing emergency resources.

The automated program checks semantic structure, one H1, language, viewport, skip link, main target, image alternatives, button labels, no query-string private forms, autofill defaults, keyboard focus, reduced motion, forced colors, print behavior, small-screen containment, security headers, and private-response cache controls. Automated checks cannot certify lived accessibility, coercion resilience, or usability. Independent human review remains `NOT_RUN_NO_AUTHORIZED_INDEPENDENT_REVIEW`.

## 12. Public architecture

Thirteen current human routes and ten current machine owners are generated from the v0.39 contract. DOC-071 joins the document and research catalogs. The site manifest, AI manifest, discovery text, feeds, sitemap, dedicated v0.39 sitemap partition, hubs, current WSGI runtime APIs, route ownership, shell, and release records share one version and evidence boundary.

The ten superseded v0.38 current API aliases are not redirects and not shadow owners. They are neutral protected 404 non-owners. Their historical HTML and data records remain available as bounded historical evidence. This retains evidence history without maintaining duplicate current runtime implementations.

## 13. Test and mutation results

Five new test families currently report 230 passing assertions: workbench 45, infrastructure lifecycle 25, receipt graph 29, database and activation 74, and rehearsal/accessibility 57. The tests include malformed files, duplicate keys, unsafe permissions, path ambiguity, signature tampering, stale epochs, database-role collision, authorization mismatch, source and signer revocation, expired evidence, orphan graphs, prohibited receipt content, all schema classifications, migration-manifest drift, forbidden SQL, silent fallback, twenty database forced failures, exact-source route mutations, four activation-stage failures, ten rehearsal prerequisites, seven rehearsal failures, HTML and CSS mutations, privacy headers, and no false operational claims.

These passing assertions are local executable evidence only. Current and fresh extraction, browser, WSGI, package, leakage, secret, hero, document, route, and checksum validation are separate release gates and are recorded separately in the delivered evidence archive.

## 14. Quality and dependability decisions

The release eliminates an unsupported package-delivery claim rather than retaining it as compatibility history. It adds deterministic and reproducible package boundaries, exact current owners, protected superseded aliases, stable failure codes, immutable input checks, manifest binding, lock-release proofs, candidate isolation, and non-circular detached sealing.

The approved hero remains byte-identical at `assets/brand/concresca-hero-approved.png`, SHA-256 `d1b88e9ec6c0f9f905cf9f173e7e947b55e1a18333aec4eff7f23194418099cd`, dimensions 1672 by 941. Raw commissioned reports, `.uai` memory, source registries, private custody inputs, credentials, databases, mutable logs, and execution authorization remain absent from the stripped site package.

## 15. Exact operational gates

- Authenticated MATM source custody: `BLOCKED_AUTHENTICATED_ARCHIVE_NOT_IN_LOCAL_CUSTODY`
- Authorized MySQL or MariaDB staging: `NOT_RUN_NO_AUTHORIZED_DATABASE`
- Production infrastructure privacy observation: `NOT_OBSERVED`
- Passenger or cPanel staging: `NOT_RUN_NO_ACCESS`
- Genuine two-agent dogfood: `BLOCKED_PREREQUISITES_NOT_SATISFIED`
- Independent human accessibility or usability review: `NOT_RUN_NO_AUTHORIZED_INDEPENDENT_REVIEW`
- Live cutover: `NOT_AUTHORIZED`

No deployment, DNS change, hosting mutation, database connection, SQL execution, migration, rollback, backup, restore, MATM import, process activation, route-owner commit, production privacy verification, genuine separate-agent workflow, independent human review, governance ratification, or certification is claimed.

## 16. Appeals, correction, deletion, and remedy

Technical evidence can be corrected without assigning blame. A correction identifies the inaccurate record, replacement, actor, reason, source evidence, time, expiry, and downstream invalidation. Superseded and revoked records remain attributable history but cannot remain current. Public projections link to `/appeals/` without exposing private evidence.

Deletion expectations are scoped by system layer. Application deletion does not prove proxy, database, backup, replica, snapshot, provider, or legal-hold deletion. Each layer requires separately owned evidence. Restore reconciliation must prevent expired, corrected, revoked, or dismantled state from returning.

## 17. Conclusion

V0.39 moves Concresca from a set of local readiness controls into a single custody, correction, execution, and activation transaction boundary. It does not transform missing operational inputs into evidence. It makes absence explicit, preserves public reading, refuses duplicate current owners, and ensures every technical state remains judgment-free.

**NO JUDGMENT WHATSOEVER.**