[Task] Produce signed target maturity and recovery evidence for a pinned release #37

New Issue

2026-08-01T16:35:47+02:00

zemion commented

2026-08-01 16:35:47 +02:00

Outcome

Produce the real target-environment evidence required before any institutional product package or module may claim reference_ready, supported, or lts.

Required evidence

Bind every claim to one exact release, installed module payload, deployment subject, control version, artifact hashes, issuer key, issuance time, and expiry.
Run and retain accessibility, privacy, security, operator, provider-health/freshness, backup/restore, rollback, and recovery-drill assessments.
Exercise the selected production topology with PostgreSQL, Redis, shared S3-compatible storage, stateless API/worker replicas, fenced singleton work, and the real ingress/trust boundary.
Record measured RTO/RPO and prove semantic reconstruction of the institutional and service/Form journeys after restore.
Verify signatures and cumulative readiness with the implemented capability-fit authority keyring and evidence schemas.
Publish only sanitized receipts and references; private reports, secrets, personal data, and recovery material remain in the approved evidence store.
Block promotion when evidence is missing, expired, bound to another release/deployment, revoked, or negative.

Boundary

Source code and local tests can verify the evidence machinery but cannot manufacture this claim. A pinned release and a real target deployment must produce it. The Committee secret-ballot provider has its own provider-selection and certification issue.

Reference: docs/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md, docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md, and docs/RECOVERY_AND_ROLLBACK_GUARANTEES.md.

## Outcome Produce the real target-environment evidence required before any institutional product package or module may claim `reference_ready`, `supported`, or `lts`. ## Required evidence - Bind every claim to one exact release, installed module payload, deployment subject, control version, artifact hashes, issuer key, issuance time, and expiry. - Run and retain accessibility, privacy, security, operator, provider-health/freshness, backup/restore, rollback, and recovery-drill assessments. - Exercise the selected production topology with PostgreSQL, Redis, shared S3-compatible storage, stateless API/worker replicas, fenced singleton work, and the real ingress/trust boundary. - Record measured RTO/RPO and prove semantic reconstruction of the institutional and service/Form journeys after restore. - Verify signatures and cumulative readiness with the implemented capability-fit authority keyring and evidence schemas. - Publish only sanitized receipts and references; private reports, secrets, personal data, and recovery material remain in the approved evidence store. - Block promotion when evidence is missing, expired, bound to another release/deployment, revoked, or negative. ## Boundary Source code and local tests can verify the evidence machinery but cannot manufacture this claim. A pinned release and a real target deployment must produce it. The Committee secret-ballot provider has its own provider-selection and certification issue. Reference: `docs/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md`, `docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md`, and `docs/RECOVERY_AND_ROLLBACK_GUARANTEES.md`.

zemion added the module/ops

type

task

codex/needs-human area/governance

labels 2026-08-01 16:35:47 +02:00

Sign in to join this conversation.