docs: define policy-driven assurance and EP governance roadmap

docs/development/ENGINEERING_PLATFORM_ROADMAP.md

@@ -1,5 +1,28 @@
 # Engineering Platform Roadmap
 
+## Policy governance and effective assurance profiles — documented target
+
+The coordinated `POLICY_GOVERNANCE_AND_EFFECTIVE_PROFILES_V1` increment adds
+[EP-owned policy/assurance architecture](../engineering/POLICY_GOVERNANCE_AND_ASSURANCE_PROFILES.md)
+and its [scoped roadmap/DAG](POLICY_GOVERNANCE_V1_ROADMAP.md).
+This is documentation, not implementation or live policy activation.
+
+EP owns effective admission, review/quality/security, validation, provider and
+repair policies; Workspace presents permitted policy management, Forge plans
+bounded work/releases, and Forge Platform composes compatible artifacts. A
+policy is not a grant, consumed budget is not an editable preference, and the
+current three-round bound cannot reset on a new SHA/PR/restart. Standalone EP
+retains approved local policy without requiring Forge or Workspace availability.
+
+The local lane is `POL-0 -> POL-E -> POL-B -> POL-Q`, with explicit release
+execution `POL-E -> VR-X -> VR-Q`. The latter joins Forge-owned release planning
+before production installer composition; it does not make a matching version
+string proof of a published artifact. All implementation nodes are PLANNED.
+Existing #100 assurance and #102 dependency admission remain separate owning
+work; this architecture does not approve or claim their implementation complete.
+Full policy-administration UI is not a new first-canary gate, and no executable
+programme DAG, installation, package version or grant changes in this increment.
+
 ## Server deployment and discovery sequencing
 
 EP's target server is headless, launchd-managed on macOS, with one EP-owned

docs/development/POLICY_GOVERNANCE_V1_ROADMAP.md

@@ -0,0 +1,56 @@
+# EP policy-governance roadmap
+
+Scoped lane under [Engineering Platform Roadmap](ENGINEERING_PLATFORM_ROADMAP.md).
+Owning design: [EP policy governance and effective assurance profiles](../engineering/POLICY_GOVERNANCE_AND_ASSURANCE_PROFILES.md).
+Increment: `POLICY_GOVERNANCE_AND_EFFECTIVE_PROFILES_V1`.
+
+The current deliverable is architecture documentation. The implementation nodes
+below are PLANNED; no active profile, grant, run or installed artifact changes.
+The cross-product documentary graph is maintained in
+`pcvantol/forge:docs/roadmap/policy-governance-v1.json` (proposal [#50](https://github.com/pcvantol/forge/pull/50)).
+This EP document owns the EP milestones, not peer readiness.
+
+| Node | Owned delivery / acceptance | Dependencies | Position |
+| --- | --- | --- | --- |
+| POL-0 | EP policy catalogue, classifications, authority and shared logical contracts documented | none | This documentation increment |
+| POL-E | EP effective validation/assurance profile services; single runwide accounting; versioned snapshots and evaluation evidence | POL-0 | PLANNED; required subset joins existing assurance work |
+| POL-B | EP half of exact materialized-request -> accepted-policy binding; fail-closed unsupported/conflicting requirements | POL-E and Forge POL-F contract | PLANNED integration |
+| POL-Q | EP proof for restart, revocation, current-candidate review, bounded repair and receipt/projection integrity | POL-B | PLANNED cross-product qualification |
+| VR-X | Execute explicit version changes/builds/publication with immutable identity; ordinary build does not allocate versions | POL-E | PLANNED execution; Forge owns version planning |
+| VR-Q | Version/release evidence roundtrip qualification | VR-X, Forge VR-F, POL-Q | PLANNED; production installer dependency |
+
+```text
+POL-0 -> POL-E ---------> POL-B -> POL-Q --+
+            |                ^            |
+            +-> VR-X --+     |            v
+                       +----> VR-Q -> consumer composition
+Forge POL-F ------------+    ^
+Forge VR-F ------------------+
+```
+
+The table specifies exact dependencies; peer labels are producer requirements,
+not EP authority over their implementation. EP can run standalone under a valid
+local profile; no new Forge/Workspace startup dependency is introduced.
+
+## Integration rules
+
+The assurance fixes in #100 should align with these policy seams without adding
+a generic workflow designer or every catalogue migration to that PR. Existing
+#102 dependency admission work remains separate. Versioning proposals must
+satisfy the native Forge/release execution boundary before adoption; this docs
+increment does not implement or approve their helper/workflow changes.
+
+The first Mission canary requires real applicable profile, review, repair and
+receipt semantics, not completion of all future policy-management capabilities.
+Full Workspace policy administration and installer UI are post-autonomy work.
+Production universal-installer composition that depends on released artifacts
+requires the release/compatibility qualification, not a matching version string.
+
+## Documentary acceptance
+
+Owner boundaries agree with the three companion designs; every catalogue entry
+has a pinned source/form; roadmap IDs match the cross-product graph; no cycles
+or implicit peer readiness; source/CI/runtime/package/permission files unchanged.
+Implementation acceptance additionally requires the concrete tests in the owning
+design and applicable installed evidence. Documentary completion alone cannot
+unlock a run or close a live assurance gate.