Status: active implementation plan
Umbrella: #667
Architecture: ../architecture/ENTERPRISE_CONTROL_PLANE.md
ADR: ../decisions/ADR-0014-enterprise-control-plane-baseline.md
Contract: ../specifications/ENTERPRISE_CONTROL_PROFILE_V0_1.md
Deliver an enterprise-operable IDKMesh profile without turning the default GitHub-first product into an infrastructure project.
The execution sequence is control-first:
E1 versioned control profile
|
+------------------------+
| |
v v
E2 tenant isolation E3 identity/SoD
| |
+------------+-----------+
|
+----------+----------+
| |
v v
E4 audit ledger E5 data/secrets
| |
+----------+----------+
|
+----------+----------+
| |
v v
E6 SLO/DR E7 supply chain
| |
+----------+----------+
|
v
E8 optional G2/G3 service
|
v
E9 destructive conformance pilot
G0/G1 work can use many of these controls without waiting for E8.
The program is not complete when all documents exist.
It is ready for a scoped enterprise pilot when evidence shows:
Deliver JSON Schema Draft 2020-12 for EnterpriseControlProfile v0.1.
Add one production-oriented example that passes the deterministic baseline.
Add deterministic PASS/WARN/FAIL checks for cross-field enterprise invariants.
At minimum:
One versioned profile can be inspected deterministically without network access, and the tool explicitly states that declaration readiness is not observed enforcement.
Suggested PR slices:
Exit: a cross-tenant reference cannot read, mutate, claim, retry, or attach evidence to another tenant.
Slices, lettered as issue #670 and the authorization kernel specification letter them. Those two are authoritative; this section’s original lettering was a suggestion that predated both and assigned different work to the same letters.
The suggestions this replaces are not lost work. Role and attribute policy evaluation, policy-revision binding, the high-risk distinct-actor requirement and the task-text escalation negatives are items 3, 4, 9, 7 and 8 of the E3-A exit gate in that specification rather than separate slices; revocation/expiry cache invalidation is E3-D above, and the break-glass object is E3-E.
Exit: authority derives from trusted identity/policy state, not task text/provider output.
Suggested slices:
Exit: privileged history can be reconstructed and silent rewrite/removal is detectable within the selected ledger model.
Suggested slices:
Exit: a task/model cannot downgrade classification, select an unauthorized secret, or route restricted data to a forbidden provider.
Suggested slices:
Exit: the operator can prove restart/restore behavior against declared objectives.
Suggested slices:
Exit: release artifacts can be traced to exact source/build identity, and provenance is verifiable without being misrepresented as correctness.
Boundary status: frozen by Enterprise Control Service Boundary v0.1.
E8 deliberately does not begin by selecting Kubernetes/Postgres/Redis. The specification now fixes the technology-neutral boundary:
Issue #675 owns this service boundary and deployment reference, not proof that a production G2/G3 service is already operating. Concrete transport/store adapters should use separate implementation issues so vendor choices remain replaceable.
Observed runtime evidence stays with its domain owners:
Exit for #675: every acceptance criterion is mapped in the normative E8 specification. A deployment may claim G2/G3 operational readiness only after the applicable E2/E3/E6/E9 evidence also exists.
Run destructive scenarios rather than a happy-path demo.
Required scenarios:
Every scenario records expected safe state and observed result.
| Domain | Primary issue | Required evidence |
|---|---|---|
| profile/contract | #668 | schema + passing/negative preflight |
| tenant isolation | #669 | adversarial cross-tenant tests |
| identity/SoD | #670 | authorization fixtures + distinct actor tests |
| audit | #671 | tamper/replay/export evidence |
| data/secrets | #672 | forbidden egress/secret negative tests |
| reliability/DR | #673 | restart + restore evidence |
| supply chain | #674 | SBOM/provenance verification |
| service boundary | #675 | restart-safe G2 + tenant-safe G3 |
| conformance | #676 | destructive scenario report |
Use platform capabilities where they strengthen the boundary:
Do not make plan-dependent capabilities silent requirements for G0. Enterprise preflight should report PASS/WARN/FAIL/UNKNOWN with the reason and feature availability.
The example enterprise profile includes concrete targets to make the contract testable.
They become claims only after observed service/pilot evidence exists.
A useful enterprise report therefore separates:
declared target
implemented mechanism
test evidence
observed production/pilot measurement
independent audit/certification
Every enterprise implementation PR should include:
For security-sensitive changes, a green worker-generated test suite is necessary but not sufficient evidence for integration.
This sequence makes enterprise hardening an evidence program rather than a collection of infrastructure features.