[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

zemion commented

2026-08-02 03:45:32 +02:00

Codex State: needs-info

Summary

Implemented the controlled target-evidence issuance and admission machinery: a bounded private run-manifest schema, signed public proof/review receipts, exact release/deployment/provider binding, independent authority-key checks, and atomic output.
Capability-fit can now require reference-readiness, external-provider proof, and production approval, and blocks missing, expired, revoked, negative, or mismatched evidence.
The tooling deliberately cannot manufacture operational evidence. The issue remains open until it is run against a pinned release in the real target topology and the required human/operator assessments are supplied.

Changed Files

tools/assessments/govoplan_assessment/boundary_evidence.py
tools/assessments/boundary-evidence.py
docs/capability-fit-boundary-run.schema.json
docs/TARGET_MATURITY_EVIDENCE_RUNBOOK.md
tools/assessments/govoplan_assessment/capability_fit.py

Verification

59 GovOPlaN assessment tests passed.
Consolidated focused checks passed.
Pushed as 2c56a0f.

Next / Blocked

Run the documented procedure for one exact release and real deployment using PostgreSQL, Redis, shared object storage, replicated stateless API/workers, singleton fencing, and production ingress/trust boundaries.
Attach approved accessibility, privacy, security, operator, provider health/freshness, backup/restore, rollback, recovery-drill, RTO, and RPO evidence through the private evidence store.

Suggested status label: status/needs-info

## Codex State: needs-info ### Summary - Implemented the controlled target-evidence issuance and admission machinery: a bounded private run-manifest schema, signed public proof/review receipts, exact release/deployment/provider binding, independent authority-key checks, and atomic output. - Capability-fit can now require reference-readiness, external-provider proof, and production approval, and blocks missing, expired, revoked, negative, or mismatched evidence. - The tooling deliberately cannot manufacture operational evidence. The issue remains open until it is run against a pinned release in the real target topology and the required human/operator assessments are supplied. ### Changed Files - `tools/assessments/govoplan_assessment/boundary_evidence.py` - `tools/assessments/boundary-evidence.py` - `docs/capability-fit-boundary-run.schema.json` - `docs/TARGET_MATURITY_EVIDENCE_RUNBOOK.md` - `tools/assessments/govoplan_assessment/capability_fit.py` ### Verification - `59 GovOPlaN assessment tests passed.` - `Consolidated focused checks passed.` - `Pushed as 2c56a0f.` ### Next / Blocked - Run the documented procedure for one exact release and real deployment using PostgreSQL, Redis, shared object storage, replicated stateless API/workers, singleton fencing, and production ingress/trust boundaries. - Attach approved accessibility, privacy, security, operator, provider health/freshness, backup/restore, rollback, recovery-drill, RTO, and RPO evidence through the private evidence store. Suggested status label: `status/needs-info`

zemion added

and removed

labels 2026-08-02 03:46:54 +02:00

zemion referenced this issue

2026-08-02 05:32:57 +02:00

[Task] Add multi-host orchestrator profile, fencing, and worker lifecycle #27

zemion referenced this issue

2026-08-03 01:16:26 +02:00

[Task] Implement supported ingress, TLS, and public-route deployment profiles #24

zemion referenced this issue

2026-08-03 02:03:52 +02:00

[Task] Integrate coordinated backup evidence and restore drills into deployment flow #35

zemion referenced this issue

2026-08-03 20:20:13 +02:00

[Task] Add multi-host orchestrator profile, fencing, and worker lifecycle #27

zemion commented

2026-08-03 20:20:14 +02:00

The target-maturity evidence can now be bound to a real immutable release rather than a placeholder:

Release: GovOPlaN v0.1.14
Source/tag/release target: 1f039dd39c1ce2672f4978c8abc6dff862ef1445
Signed manifest SHA-256: d703267e01855dee63200cb20921c91c3f95fbff550c8ca76e9a35cba3f69109
Composition SHA-256: 613a14fb085c3f5670c35d0a15b9b98e3af644b6bb39ab9afdd8bd54c2c58d33
Signing key: runtime-distribution-2026-01
API index: git.add-ideas.de/govoplan/runtime-api@sha256:197ed01790986f2bc927eaa5d8348fa118702e5d2dc05feb851fc2643c23764a
WebUI index: git.add-ideas.de/govoplan/runtime-web@sha256:e936cca124f1fad29a067834cf17627d4c236410fdc3fa129e0ccb26b8193812

The release checksums, external-key signature, source/provenance subjects, OCI indexes and platform children, non-root image identities, cross-architecture runtime receipts, and managed ingress were independently verified. #21 and #22 are closed; the signed subject prerequisite for this issue is complete.

What remains is intentionally target- and authority-owned. Follow docs/TARGET_MATURITY_EVIDENCE_RUNBOOK.md against the real topology and provide:

opaque report and control IDs from the approved private evidence store for target environment, accessibility, privacy, security, operations, and recovery;
external PostgreSQL, Redis, shared S3, replicated stateless runtime, fenced singleton, real ingress/trust-boundary, provider-health, backup/restore, rollback, and forward-recovery results;
measured RTO/RPO and semantic reconstruction of the institutional and Service/Form journeys;
separately custodied authority keyring/private keys covering each claim, with an independent production approver;
the installed-composition receipt and #27 Kubernetes receipt bound to this exact release/deployment.

This workspace has neither a target cluster nor approved private evidence-store references or independent authority keys, so generating a positive proof here would violate the evidence model. Run boundary-evidence.py and then capability-fit.py --require-reference-readiness --require-production-approval on the controlled assessment host. Attach only the sanitized signed proof and review receipt here; raw reports, keys, endpoints, recovery material, and personal data remain private.

The target-maturity evidence can now be bound to a real immutable release rather than a placeholder: - Release: [GovOPlaN v0.1.14](https://git.add-ideas.de/GovOPlaN/govoplan/releases/tag/v0.1.14) - Source/tag/release target: `1f039dd39c1ce2672f4978c8abc6dff862ef1445` - Signed manifest SHA-256: `d703267e01855dee63200cb20921c91c3f95fbff550c8ca76e9a35cba3f69109` - Composition SHA-256: `613a14fb085c3f5670c35d0a15b9b98e3af644b6bb39ab9afdd8bd54c2c58d33` - Signing key: `runtime-distribution-2026-01` - API index: `git.add-ideas.de/govoplan/runtime-api@sha256:197ed01790986f2bc927eaa5d8348fa118702e5d2dc05feb851fc2643c23764a` - WebUI index: `git.add-ideas.de/govoplan/runtime-web@sha256:e936cca124f1fad29a067834cf17627d4c236410fdc3fa129e0ccb26b8193812` The release checksums, external-key signature, source/provenance subjects, OCI indexes and platform children, non-root image identities, cross-architecture runtime receipts, and managed ingress were independently verified. #21 and #22 are closed; the signed subject prerequisite for this issue is complete. What remains is intentionally target- and authority-owned. Follow `docs/TARGET_MATURITY_EVIDENCE_RUNBOOK.md` against the real topology and provide: - opaque report and control IDs from the approved private evidence store for target environment, accessibility, privacy, security, operations, and recovery; - external PostgreSQL, Redis, shared S3, replicated stateless runtime, fenced singleton, real ingress/trust-boundary, provider-health, backup/restore, rollback, and forward-recovery results; - measured RTO/RPO and semantic reconstruction of the institutional and Service/Form journeys; - separately custodied authority keyring/private keys covering each claim, with an independent production approver; - the installed-composition receipt and #27 Kubernetes receipt bound to this exact release/deployment. This workspace has neither a target cluster nor approved private evidence-store references or independent authority keys, so generating a positive proof here would violate the evidence model. Run `boundary-evidence.py` and then `capability-fit.py --require-reference-readiness --require-production-approval` on the controlled assessment host. Attach only the sanitized signed proof and review receipt here; raw reports, keys, endpoints, recovery material, and personal data remain private.

zemion commented

2026-08-04 14:38:09 +02:00

Codex State: needs-info

Summary

Controlled target evidence can run in one-shot containers, but container isolation does not create independent approval authority.
The handoff now separates installer, target-assessment, and production-approval keys and provides a safe Ed25519 authority-key generator with schema validation and overwrite refusal.

Changed Files

docs/PRODUCTION_TARGET_HANDOFF.md
docs/TARGET_MATURITY_EVIDENCE_RUNBOOK.md
tools/assessments/generate-authority-keypair.py

Verification

tests.test_assessment_authority_keypair: passed

Next / Blocked

An independent production approver must hold a separate key and review the real target evidence; the operator must provide the pinned deployment and private evidence store.

Suggested status label: status/needs-info

## Codex State: needs-info ### Summary - Controlled target evidence can run in one-shot containers, but container isolation does not create independent approval authority. - The handoff now separates installer, target-assessment, and production-approval keys and provides a safe Ed25519 authority-key generator with schema validation and overwrite refusal. ### Changed Files - `docs/PRODUCTION_TARGET_HANDOFF.md` - `docs/TARGET_MATURITY_EVIDENCE_RUNBOOK.md` - `tools/assessments/generate-authority-keypair.py` ### Verification - `tests.test_assessment_authority_keypair: passed` ### Next / Blocked - An independent production approver must hold a separate key and review the real target evidence; the operator must provide the pinned deployment and private evidence store. Suggested status label: `status/needs-info`

zemion commented

2026-08-04 16:55:10 +02:00

Codex State: needs-info

Summary

GovOPlaN v0.1.15 supplies the pinned signed runtime subject and retained package-lock, provenance, SBOM, and cross-architecture smoke evidence needed to begin the controlled target assessment.
The collector, schema validation, proof issuance, authority-scope separation, independent review, and admission machinery are implemented and documented in docs/PRODUCTION_TARGET_HANDOFF.md and docs/TARGET_MATURITY_EVIDENCE_RUNBOOK.md.

Next / Blocked

The organization must designate separately controlled installer, target-assessment, and production-approval authorities; generate their private keys independently; identify the controlled evidence store/custodians; and provide only public keyrings and approved local secret-mount paths. The independent approver must not share the operator/assessor key boundary.

Suggested status label: status/needs-info

## Codex State: needs-info ### Summary - GovOPlaN v0.1.15 supplies the pinned signed runtime subject and retained package-lock, provenance, SBOM, and cross-architecture smoke evidence needed to begin the controlled target assessment. - The collector, schema validation, proof issuance, authority-scope separation, independent review, and admission machinery are implemented and documented in docs/PRODUCTION_TARGET_HANDOFF.md and docs/TARGET_MATURITY_EVIDENCE_RUNBOOK.md. ### Next / Blocked - The organization must designate separately controlled installer, target-assessment, and production-approval authorities; generate their private keys independently; identify the controlled evidence store/custodians; and provide only public keyrings and approved local secret-mount paths. The independent approver must not share the operator/assessor key boundary. Suggested status label: `status/needs-info`

zemion referenced this issue

2026-08-05 22:00:55 +02:00

[Task] Add multi-host orchestrator profile, fencing, and worker lifecycle #27

zemion commented

2026-08-05 22:01:15 +02:00

Codex State: pinned rehearsal input available

The target-evidence pipeline now has a clean immutable rehearsal subject and a passing bounded Kubernetes receipt:

release v0.1.18
signed manifest SHA-256 7003232331780add84a167169398918c707b19a9f8e8329c0d105184ee4d6009
API index git.add-ideas.de/govoplan/runtime-api@sha256:be9fb2b14b03232b820ee9bdb57d4ad34b753f28765813eac728bf1869ccb8dc
Web index git.add-ideas.de/govoplan/runtime-web@sha256:54a1a6ab0a304f22a852d6fa131c598de4ec8287a5a5a880e36b2a3f0217f2d6
Kubernetes rehearsal receipt SHA-256 259f8e33b7b7a7161e1278f3ae94d52d99d88fcc2659fd1f1f8a2808cfb08abc
all snapshot checks passed; API pod deletion/replacement caused zero observed readiness failures.

The live drill also found and fixed the API endpoint-drain race (GovOPlaN/govoplan@389df7c) rather than weakening the evidence threshold.

This advances #37 but does not satisfy its production claim. The current state services are deliberately on one lab VM and both Kubernetes workers share one physical hypervisor. No independent production approver has signed the receipt, and no controlled accessibility/privacy/security/operator/provider assessment or coordinated backup/isolated-restore/rollback/recovery drill with measured RTO/RPO has been supplied.

The next valid run must therefore:

repeat #27 on independent physical failure domains with the real ingress/trust boundary;
use externally operated HA PostgreSQL, Redis and S3-compatible storage;
create and adopt signed coordinated backup evidence after an isolated restore and semantic reconstruction test;
exercise session continuity, accepted-job redelivery, worker/node loss, rollback/forward recovery and the maintained institutional/service journeys;
bind the private assessment references to this exact deployment subject and obtain a separately custodied production-approval signature.

Keep status/needs-info and codex/needs-human; source code cannot honestly manufacture those authority- and target-owned facts.

## Codex State: pinned rehearsal input available The target-evidence pipeline now has a clean immutable rehearsal subject and a passing bounded Kubernetes receipt: - release `v0.1.18` - signed manifest SHA-256 `7003232331780add84a167169398918c707b19a9f8e8329c0d105184ee4d6009` - API index `git.add-ideas.de/govoplan/runtime-api@sha256:be9fb2b14b03232b820ee9bdb57d4ad34b753f28765813eac728bf1869ccb8dc` - Web index `git.add-ideas.de/govoplan/runtime-web@sha256:54a1a6ab0a304f22a852d6fa131c598de4ec8287a5a5a880e36b2a3f0217f2d6` - Kubernetes rehearsal receipt SHA-256 `259f8e33b7b7a7161e1278f3ae94d52d99d88fcc2659fd1f1f8a2808cfb08abc` - all snapshot checks passed; API pod deletion/replacement caused zero observed readiness failures. The live drill also found and fixed the API endpoint-drain race (`GovOPlaN/govoplan@389df7c`) rather than weakening the evidence threshold. This advances #37 but does not satisfy its production claim. The current state services are deliberately on one lab VM and both Kubernetes workers share one physical hypervisor. No independent production approver has signed the receipt, and no controlled accessibility/privacy/security/operator/provider assessment or coordinated backup/isolated-restore/rollback/recovery drill with measured RTO/RPO has been supplied. The next valid run must therefore: 1. repeat #27 on independent physical failure domains with the real ingress/trust boundary; 2. use externally operated HA PostgreSQL, Redis and S3-compatible storage; 3. create and adopt signed coordinated backup evidence after an isolated restore and semantic reconstruction test; 4. exercise session continuity, accepted-job redelivery, worker/node loss, rollback/forward recovery and the maintained institutional/service journeys; 5. bind the private assessment references to this exact deployment subject and obtain a separately custodied production-approval signature. Keep `status/needs-info` and `codex/needs-human`; source code cannot honestly manufacture those authority- and target-owned facts.

zemion referenced this issue

2026-08-05 22:03:04 +02:00

[User Story] One-command Core bootstrap, module lifecycle, scale-out, and environment promotion #13

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan#37