Architecture and release boundaries

Request path

A browser loads the compiled frontend through Caddy and the active Node API’s static frontend handler. The guided flow orchestrates county/tract queries and the map; the project workspace exposes the configured project and review/export workflows.

The application boundary authenticates requests, validates request shape, enforces per-action membership and source permissions, and reads accepted providers. Protected JSON carries schemaVersion and requestId and is marked private/no-store.

Browser (guided flow / workspace)
  → Caddy public route
  → active Node API
      → PostgreSQL: project, membership and evidence metadata
      → read-only U3a runtime: existing county/record evidence
      → read-only M1 runtime: tract measures and U4 facilities
      → export artifacts
Existing worker → database jobs → export artifacts

Frontend modules

Runtime data boundary

U3b mounts the retained source packages, the M1 runtime and the combined annex configuration read-only in the API and worker. Existing p8 releases and grants are retained; D6 successor versions and the additive storm release support newly captured annexes.

The M1 manifest and accepted wrapper bind package bytes to reviewed receipts. Providers fail closed when shape, hashes, admissions or permissions are invalid. Config changes for revocation use reviewed receipt chains and atomic replacement; directory mounts ensure the next read observes replacement.

Data files are not a substitute for database authorization. An account must still have the required organization/project role and source-specific access. Runtime catalogs describe current capabilities, not a permanent guarantee of coverage.

Jobs, artifacts and persistence

The U3b worker processes durable jobs with the same admitted annex configuration as the API, and writes frozen export artifacts. Source authority and registry permissions are checked at execution and publication. The database remains at schema 59.

Annex exports are tied to existing admitted evidence and a pinned snapshot. Browser exploration, a copied view URL and a completed export are different persistence surfaces. Do not describe a copied overlap link as an immutable report.

U3b crosses this boundary through an admitted combined runtime, D6 successor registry releases, a separate D5 storm release, and matching API/worker annex configuration. Activation requires validated data, a drained queue, project re-pinning, worker replacement and a reversible route switch.

Deployment and rollback topology

U3b is staged on an explicit loopback candidate, checked again on the active target, then routed through Caddy. The release receipt binds actual ports, image and container identities. Previous API, worker and data packages remain available during rollback verification.

The U3b switch keeps schema 59 but changes the worker and the project’s registry selection. Recovery therefore includes receipt-bound reverse re-pinning and a stop-before-start worker transition, as well as restoring prior route bytes. It is separate from database restoration across an earlier migration.

Source revocations remain effective through their staged runtime configuration. A rollback route is not authorization to restore withdrawn source rights.

Optional surfaces are not automatic product promises

The repository contains broader identity, integration, Watch, review and specialized workspace modules. They are assembled only when the configured runtime supplies their providers, stores, grants and acceptance requirements.

The route inventory documents implemented registrations. It is not a list of live enabled APIs, a claim of enterprise SSO readiness, or proof that notification transports are delivering. Use the current runtime/capability evidence before documenting an optional feature as available.