# DOC-073 — Reproducible Authorization, Sandboxed Adapters, Multi-Epoch Non-Resurrection, and Liquid Status Repair

## Abstract

Concresca v0.41 makes authorization replayable, adapter capability explicit, correction and deletion durable across repeated restore epochs, and status remediation visible at the exact point where an operator encounters a blocker. It also performs a UI/UX deep dive that preserves the established Concresca identity while replacing breakpoint cliffs, fixed-column assumptions, and an oversized status-first viewport with one liquid layout system.

This release remains WIP. Local mechanism tests, generated documents, public-origin observation, screenshots, and direct WSGI calls do not establish authenticated MATM source custody, an authorized MySQL/MariaDB staging run, production infrastructure privacy, Passenger/cPanel configuration, genuine two-agent dogfood, independent human accessibility review, exact deployed-package identity, protected runtime activation, or live cutover authorization. Those propositions remain separate throughout the human interface, machine owners, evidence records, and packaging.

## Live-source observation and epistemic boundary

The operator-directed live review on 2026-09-03 found that the public homepage identified v0.40 while `/status/` still presented multiple historical version labels and an undifferentiated “Not deployed” statement. The reachable public documentation surface proves that an origin responded with content. It does not identify the exact package bytes being served, establish that the coordination runtime is active, reveal Passenger or cPanel configuration, prove database authority, or verify any other protected operational layer.

The current local release therefore uses the bounded proposition `PUBLIC_DOCUMENTATION_OBSERVED_RUNTIME_NOT_ACTIVATED_PACKAGE_IDENTITY_UNVERIFIED`. It separates public reachability, package identity, runtime activation, source custody, database execution, infrastructure privacy, human review, and cutover. Historical live observations are preserved as observations, not silently rewritten as current local implementation claims.

No browser availability, HTTP 200 response, green presentation, test pass, screenshot, or fluent status prose may upgrade a blocked, unobserved, unauthorized, or unknown operational state. The status page uses exact technical conditions rather than participant evaluation. NO JUDGMENT WHATSOEVER.

## Status-page UI/UX findings

The baseline status page carried valuable material but made the highest-priority operator task unnecessarily difficult. On mobile, the hero consumed the first viewport before the current state or repair path appeared. On desktop, the hero and manifesto dominated above-the-fold space while the actionable vector began below it. The current-owner table extended beyond the shared reading measure and required horizontal scanning. Version fragments from multiple historical releases competed for attention without explaining which file controlled the present output.

The central usability defect was not merely visual density. A person who found a failed or blocked gate could not answer four immediate questions from the page: what exactly is wrong, where is the authoritative source file, what sequence safely corrects it, and what evidence is required before the state may change. The page described states but did not function as a remediation interface.

v0.41 changes that information architecture. The first viewport now presents a compact status statement, a six-proposition current vector, and a direct anchor to “Where and how to fix open gates.” The remediation area uses native `details` elements so it works without JavaScript. Every fix card includes an exact state, explanation, repository owner, generated/public owner where applicable, safe repair steps, required evidence, authorization boundary, verification command or operator runbook, and the proposition that must remain unchanged when evidence is absent.

The status page does not expose private paths, account identifiers, credentials, live database names, raw configuration, logs, or private evidence. File paths are repository-relative and point only to packaged source, public projection, or non-secret runbook locations.

## Preserved visual identity

The deep dive intentionally does not redesign Concresca into a different brand. The approved hero remains a real DOM image at `assets/brand/concresca-hero-approved.png`, with SHA-256 `d1b88e9ec6c0f9f905cf9f173e7e947b55e1a18333aec4eff7f23194418099cd` and dimensions 1672 × 941. The dark green and teal surfaces, warm gold evidence cues, serif display hierarchy, quiet bordered cards, freedom bar, and judgment-free language remain recognizable.

The release consolidates those choices into one current shell rather than accumulating parallel stylesheets or compatibility selectors. Current pages use `assets/ui-v041.css`, `body.v041-shell`, `data-shell-version="v041"`, and the current first-party `assets/site.js`. Historical documents remain historical content, but historical shell ownership is not allowed to control the current interface.

Color continues to support—not replace—written state. Gate badges contain full technical text. The status vector labels each proposition directly. Gold is used for emphasis and evidence cues rather than a universal “verified” signal. Blocked, not observed, not run, unverified, and local-only states remain explicit in text and machine data.

## Liquid layout contract

“Liquid Layout” means that spacing, typography, card widths, content measure, and navigation density interpolate across the available space instead of jumping between a small set of fixed canvases. The current shell uses fluid values bounded by minimum and maximum values. It does not stretch reading text indefinitely on ultrawide displays and does not force desktop card counts onto narrow screens.

The primary gutter is `clamp(.875rem, 2.2vw, 3.5rem)`. The wide content ceiling is 92rem. Reading text is constrained to approximately 76 characters. Display typography uses `clamp()` so headings remain prominent at wide sizes without overwhelming mobile. Card collections use `repeat(auto-fit, minmax(...))`, allowing the component’s available width—not only the viewport—to determine flow. Container queries provide progressive refinement where supported; the base grid remains usable without them.

The shell explicitly addresses widths of 320, 390, 768, 1024, 1365, 1440, and 1920 CSS pixels. These are test observations, not the only supported widths. Intermediate widths inherit the same fluid equations. No horizontal page overflow is permitted at the audited sizes. Long technical states may break at underscores or safe boundaries without clipping. Archival data tables retain bounded horizontal scrolling because their column relationships matter, while current operational status is rendered as reflowing cards instead of forcing a wide table onto a phone.

Primary links and controls maintain a minimum target size of 44 CSS pixels where they function as controls. Focus visibility remains explicit. Reduced-motion rules suppress nonessential transitions. Forced-colors rules preserve borders and link recognition. Print rules remove nonessential navigation and retain readable content. The shell remains first-party-only and adds no tracking, analytics, font network request, or external runtime dependency.

## Responsive behavior by range

At narrow-phone widths, the menu becomes a keyboard-operable disclosure, the status call to action appears within the first viewport, cards stack into one column, long state labels wrap safely, and native remediation details expose their summaries without requiring script. The hero image remains proportionate and is not used as a CSS background that can disappear from document structure.

At large-phone and small-tablet widths, the layout increases breathing room continuously rather than switching to a separate fixed template. Card minimums allow two columns only where the component actually has room. Reading measure stays bounded. The status vector can become a compact two-column set without forcing source paths into narrow cells.

At tablet and laptop widths, navigation, status vector, source locator, and remediation cards use available horizontal space while preserving scan order. The source locator remains in the same content system instead of becoming an unrelated full-width table. At desktop and ultrawide widths, the 92rem ceiling prevents cards and lines from becoming too wide; additional space becomes margin, not cognitive load.

The tested liquid behavior is monotonic: increasing viewport width does not unexpectedly reduce the principal heading size, narrow the usable content region, or increase page overflow. Component wrapping can change because available space changes, but information order and semantic relationships remain stable.

## Component-by-component improvements

The site header retains the established wordmark and navigation language. Its spacing now uses shared fluid tokens. The mobile menu preserves the same navigation rather than presenting a reduced or alternate information architecture. Keyboard Escape closes the scripted menu, and the underlying links remain ordinary links.

The hero component retains its image, kicker, heading, lede, and state label, but status pages use a compact variant. This prevents brand expression from displacing the operational task. General pages may still use the more expressive composition. The compact status hero is therefore a purpose-specific density change, not a brand replacement.

Evidence and freedom cards use auto-fit behavior, consistent internal spacing, readable line length, and explicit headings. Cards no longer assume a fixed three-column desktop. The visual border and surface treatment remain quiet, keeping state language more prominent than ornament.

Status-vector cards separate public documentation reachability, exact package identity, coordination runtime activation, source custody, database staging, and production infrastructure evidence. This prevents “site is reachable” from being mistaken for “runtime is activated” or “production is ready.”

The remediation map replaces an opaque owner table with task-focused fix cards. Each summary is scannable; opening it reveals exact files and steps. Native disclosure means a person can access the instructions with JavaScript disabled. The “Repository source locator” identifies the generator, generated page, current stylesheet, source JSON owner, public machine projection, runtime loader, WSGI dispatch, route registry, regeneration command, validation command, browser-audit command, and packaging command.

Code and path values use wrapping rules that preserve the complete value. They are never truncated with an ellipsis that would make the path unusable. State badges use safe break opportunities without changing the canonical machine value.

## Status remediation contract

The current remediation owner is `data/_source/v041-status-remediation-map.json`. It is the machine-readable source for the human fix cards and public projection `/data/v041-status-remediation-map/`. The generator `scripts/build-v041-liquid-authorization.py` renders that owner into `status/index.html`; the page is not intended to be hand-edited after generation.

Each remediation record has a stable gate identifier, current state, human summary, source owners, generated/public projection, numbered safe steps, evidence required for a state transition, authorization requirement, correction route, limitation, and participant-evaluation and standing effects `NONE`. The model covers local status parity, live package identity, authenticated MATM source, MySQL/MariaDB staging, infrastructure privacy, Passenger/cPanel inspection, two-agent dogfood, independent accessibility review, and live cutover.

A local correction may update generated source and tests. An operational correction may not occur merely because a path or instruction exists. Database, source intake, host inspection, dogfood, external review, deployment, and cutover require separately supplied authority and evidence. The page says where such evidence belongs but does not place secrets or private evidence in the public root.

A state changes only when the exact proposition’s required evidence exists. One gate cannot borrow another gate’s evidence. For example, a deployment receipt cannot prove database semantic restore; a database staging run cannot prove Passenger logging behavior; an automated browser audit cannot prove independent human accessibility review; and a reachable origin cannot prove exact package identity.

## Repository file-location map

The canonical UI generator is `scripts/build-v041-liquid-authorization.py`. It creates the current pages, data owners, runbooks, current release record, DOC-073, discovery resources, feeds, sitemaps, and status remediation interface.

The generated human status page is `status/index.html`. The current visual shell is `assets/ui-v041.css`. Shared first-party interaction behavior is `assets/site.js`. The approved hero is `assets/brand/concresca-hero-approved.png`.

The machine status source is `data/_source/v041-status-remediation-map.json`. Its public static owner is `/data/v041-status-remediation-map/`, and its current API owner is `/api/concresca/status-remediation-map`. The current data contract loader is `concresca_runtime/v041_contracts.py`. WSGI dispatch is `concresca_runtime/application.py`. Canonical and retired route ownership is `concresca_runtime/route_ownership.json`.

The release validator is `scripts/validate-v041-release.py`. Direct in-process HTTP evidence is produced by `scripts/http-smoke-v041.py`. Responsive and interaction evidence is produced by `scripts/audit-v041-interface.py`. The stripped public stage is created by `scripts/build-v041-site-stage.py`. The non-mutating operator package is created by `scripts/build-v041-cutover-stage.py`. Deterministic ZIP construction is owned by `scripts/package-v041-wip.py`, strict extraction by `scripts/safe-extract-v041.py`, and package inspection by `scripts/package-audit-v041.py`.

Repository-only operational instructions are grouped under `deployment/`: authenticated MATM intake, four-role database staging, 21-layer privacy evidence, Passenger/cPanel inspection, dogfood prerequisites, independent accessibility review, deployment receipts, and live cutover. Those files describe evidence shape and safe operator sequence; they do not carry authority, credentials, or proof that the action occurred.

## Reproducible authorization ledger

The authorization ledger records plan creation, signer verification, authorization issue, expiry, revocation, admission, refusal, start, completion, cancellation, rollback, correction, and downstream invalidation. Event and authorization identifiers derive from non-circular digests. Every event binds predecessor, actor, signer, key ID, algorithm, key epoch, capsule, plan, adapter, configuration epoch, rollback target, environment, permitted operations, time, correction route, limitation, participant-evaluation effect `NONE`, and standing effect `NONE`.

Forks, missing predecessors, duplicate events, backward sequence, time reversal, scope broadening, signer substitution, key-epoch mixing, reused cancellation tokens, execution after expiry or revocation, and completion without matching admission/start fail closed. Candidate validation occurs before mutation, so a refused append cannot partially alter the authoritative chain. Renewal creates a new attributable authorization record rather than extending old authority in place.

The included HMAC test signatures are deterministic fixtures for local adversarial testing. They are not an operational key-management system, production signer, or authority delegation. No secret key is packaged as deployment authority.

## Sandboxed adapter boundary

Every adapter publishes a signed, content-free capability manifest. Effective authority is the strict intersection of capsule operations, finite authorization scope, adapter capabilities, environment policy, one configuration epoch, and current non-revoked key state. Empty, ambiguous, expired, corrected, or revoked intersections produce no invocation.

The default package state is `NO_EXTERNAL_ADAPTER`. The local reference adapter reads one exact synthetic fixture below one explicitly supplied root and emits only a digest and byte count. It rejects traversal, symlink escape, path substitution, digest mismatch, size mismatch, undeclared operation, undeclared path, scope broadening, cancellation, and epoch mismatch. It performs zero network calls, database connections, SQL statements, archive extractions, process spawns, or implicit environment reads.

This local fixture proves properties of the adapter protocol implementation only. It does not establish that a production database, MATM archive, host, cPanel account, or other external target was accessed safely.

## Four-role database and atomic MATM activation

The database protocol preserves four distinct roles: migration target, forced-rollback database, backup source, and restore target. The v0.41 adapter binds the existing v0.40 refusal and transaction model to exact authorization and capability records. It refuses role collisions, unknown or partial schema state, migration-manifest drift, account-level SQL, prohibited profile fields, backend ambiguity, silent SQLite/JSON/file/memory fallback, mixed configuration epochs, absent rollback, and missing completion evidence.

The migration manifest and migrations remain pinned. A real run requires operator-created restricted databases, a private mode-0600 configuration outside packages and command lines, exact backend identity, advisory locking, ordered migration, forced failure in a disposable role, backup, separate restore, semantic comparison, and a content-free receipt. No database driver was imported for operational use, no connection was opened, and no SQL, migration, rollback, backup, or restore occurred in this local build.

MATM activation requires exact archive custody, member identity, license and notice, callable semantics, upstream-suite evidence, backend and private-query receipts, immutable staging, collision analysis, no-body rehearsal, finite authorization admission, one route-owner commit, one activation receipt, and one rollback owner. Failure before the commit preserves the existing public route owner. Source remains `BLOCKED_AUTHENTICATED_ARCHIVE_NOT_IN_LOCAL_CUSTODY` because no authenticated archive was supplied.

## Multi-epoch non-resurrection

Backups preserve historical bytes but do not confer current authority. The modeled sequence spans current state, backup A, correction, revocation, expiry, backup B, restore A, reconciliation, restore B, reconciliation, and final current state. Raw private inquiry, expired receipts, revoked credentials, corrected messages, superseded owners, deleted citations, expired authority, and invalidated cache projections remain non-current after reconciliation.

Correction, deletion, expiry, and revocation are represented as durable graph facts with downstream invalidation. A restored snapshot must reconcile against the current correction and invalidation graph before it can become current. An older snapshot cannot erase later tombstones. A newer backup cannot reactivate a record whose authority expired after the backup. Repeating restore and reconciliation must converge rather than oscillate.

The model distinguishes historical preservation from public availability and current authority. Evidence necessary to prove a correction may be retained privately while the corrected private body remains absent from public and ordinary recall surfaces.

## Key compromise recovery

Key identity, key epoch, delegation, rotation, revocation, compromise, recovery, and authorization invalidation are append-only events. Compromising an ancestor invalidates descendant authority within the modeled delegation graph. Recovery creates a new key epoch and does not automatically reauthorize old plans, adapters, operations, or execution targets.

A rotated key does not retroactively make an old signature valid for a new epoch. A corrected signer record does not erase the original history. Operational recovery would require separately protected key custody and an authorized incident process; the package contains only content-free protocol and local test fixtures.

## Confidential accessibility

Public reading, confidential inquiry, protected communication, account capability, optional privacy-preserving age assertion, identity verification, guardian involvement, jurisdiction-specific requirements, emergency-resource presentation, and operator disclosure remain separate. Behavioral-age inference, universal identity verification, and automatic guardian visibility remain prohibited.

The model includes shared-device, school-monitoring, public-terminal, coercive-household, unsafe-guardian, low-bandwidth, no-JavaScript, screen-reader, keyboard, zoom, reflow, reduced-motion, and forced-colors cases. It does not assume that a household, school, operator, or guardian is safe. Public documentation remains available without constructing a participant profile.

Automated checks verify document structure, skip links, focus behavior, target sizes, overflow, source-locator presence, native details behavior, responsive screenshots, reduced-motion rules, forced-colors rules, and print rules in the tested local environment. They cannot establish comprehension, real assistive-technology behavior across every combination, trauma-informed usability, safety on a monitored device, or independent certification. The corresponding gate remains `NOT_RUN_NO_AUTHORIZED_INDEPENDENT_REVIEW`.

## Validation and browser evidence

The UI audit renders the current repository, stripped site stage, fresh repository extraction, and fresh site extraction at seven widths. It checks the homepage, status page, representative operator/developer/freedom/observation/document routes, one-H1 and main structure, current shell ownership, menu operation, keyboard Escape, touch-target minimums, page overflow, hero identity, source-locator completeness, native no-JavaScript disclosures, fluid heading behavior, representative contrast, reduced motion, forced colors, and print rules.

Direct WSGI evidence enumerates canonical pages, exact machine interfaces, discovery resources, current and retired API owners, health/readiness states, host validation, neutral errors, MIME types, ETags, HEAD behavior, blocked private paths, and no-body request handling. It is in-process evidence, not Passenger, cPanel, CDN, TLS, WAF, external network, or production evidence.

Current and fresh validators rerun the v0.41 authorization, adapter, and key-epoch suites plus the inherited v0.40 evidence capsule, evidence lifecycle, database transaction, route activation, receipt/deletion graph, no-body accessibility, and operator-workbench controls. Fresh extraction matters because an editable worktree can accidentally depend on omitted files, caches, or untracked state.

## Where and how status is fixed

Regenerate current source-derived pages with `python3 scripts/build-v041-liquid-authorization.py`. Validate the repository with `python3 scripts/validate-v041-release.py --root . --report reports/v041-release-validation.json --label current-repository`. Run direct WSGI evidence with `python3 scripts/http-smoke-v041.py --root . --report reports/v041-http-smoke.json --label current-repository`. Run the browser audit with `python3 scripts/audit-v041-interface.py --root . --report reports/v041-browser-audit.json --shots reports/v041-browser-shots --label current-repository`.

Build the stripped site with `python3 scripts/build-v041-site-stage.py --root . --output ../stage/site`. Build the non-mutating cutover bundle with `python3 scripts/build-v041-cutover-stage.py --root . --output ../stage/cutover`. Construct deterministic WIP archives with `python3 scripts/package-v041-wip.py` only after current and staged validation passes. These commands do not deploy the site.

A live correction requires explicit authorization, an exact `c41-site-wip.zip` digest, extracted manifest digest, target and configuration epoch, rollback package, finite authorization record, start/end evidence, content-free deployment receipt, post-deployment parity check, and correction route. Until those exist, the local fix must remain distinct from the live public observation.

## Evidence and judgment boundary

Implemented locally: the current liquid shell, compact status information architecture, exact remediation-source map, deterministic authorization ledger, adapter capability intersection, key lifecycle and compromise propagation, multi-restore reconciliation model, current machine owners, generated public pages, local tests, direct WSGI evidence, browser evidence machinery, and WIP packaging controls.

Not supplied or verified: authenticated MATM source, operational signer and key custody, authorized four-role MySQL/MariaDB environment, production infrastructure configurations, Passenger/cPanel access, genuine separate-agent staging, independent human accessibility/usability review, exact live package identity, protected runtime activation, and live cutover authority.

Cancellation, refusal, expiry, revocation, timeout, rollback, correction, deletion, blocked source, missing database, unobserved configuration, and absent review are technical states. They do not evaluate a participant, thought, query, belief, identity, or standing. NO JUDGMENT WHATSOEVER.