diff --git a/workplans/NK-WP-0027-reef-placement-reconciliation.md b/workplans/NK-WP-0027-reef-placement-reconciliation.md
index 88e8191..d66f671 100644
--- a/workplans/NK-WP-0027-reef-placement-reconciliation.md
+++ b/workplans/NK-WP-0027-reef-placement-reconciliation.md
@@ -4,13 +4,13 @@ type: workplan
 title: "Reconcile reef placement and security-zone canon dependencies"
 domain: infotech
 repo: net-kingdom
-status: active
+status: backlog
 flavor: residual
 owner: net-kingdom
 topic_slug: netkingdom
 planning_priority: P1
 created: "2026-08-19"
-updated: "2026-10-03"
+updated: "2026-10-15"
 state_hub_workstream_id: "965ad365-6b81-50a1-a2a3-2d0c1fcce0b4"
 ---
 
@@ -240,9 +240,9 @@ is externally owned:
 3. `info-tech-canon` rules the `public`/synthetic relationship, after which
    ops-warden can update `dataclass_floor` (T06).
 
-The workplan is `blocked` rather than left nominally active with every open task
-at `wait`. No human intervention is required yet; owner responses are the
-ordinary next input.
+The workplan is deliberately `backlog` following the October 15 owner
+prioritization below. The three open tasks retain their `wait` status and
+owner dependencies. Their completion is not required for current operations.
 
 ## Related
 
@@ -278,3 +278,62 @@ Evidence and cross-plan priorities: [estate review](../history/2026-09-28-open-w
 > critical path (identity → authz → secrets → SecurityCase execution). Tasks are unchanged;
 > promote back when demand or risk appears. See the-custodian
 > `history/20261011-netkingdom-security-progress-assessment.md`.
+
+
+## Resumption approach — 2026-10-15
+
+Owner requested that this work remain in backlog after reviewing its value.
+From NetKingdom's point of view, the benefit is reliable policy input: a
+workload's availability claim must respect the substrate's evidenced ceiling,
+and disclosure classification must have an explicit maturity mapping. This
+work improves the accuracy of declarations and policy decisions; it does not
+itself add redundancy or improve uptime. For the current small team, pursue
+it when a concrete consumer needs the result rather than for declaration
+coverage alone.
+
+**Resume when** a named deployment-admission or credential-policy consumer
+will use reef ceilings or the public-data maturity floor, or a concrete risk
+review identifies an overstated availability claim that needs mechanical
+prevention. Record the consumer, the decision it needs to make, its responsible
+owner, and the acceptance example before promoting the plan. Do not infer
+renewed demand merely from the presence of waiting tasks.
+
+**Start from the existing proposal**, `docs/reef-posture-provider-contract.md`,
+and recheck current owner sources. On October 15, the authoritative
+`reef-railiance/declarations/reef.yaml` still has no `posture_provider` block;
+InfoTechCanon's Data Model includes `public`, while ops-warden's
+`registry/policy/security-posture.yaml` still has no public maturity floor.
+These source checks establish the outstanding artifacts, not owner acceptance
+of the proposal or a fresh runtime topology measurement.
+
+Use this sequence when picking the work up:
+
+1. **Settle the reef contract (T02).** Prepare a concrete schema/declaration
+   change with repo-manager and railiance-infra. Repo-manager accepts the
+   authoritative carrier and field names; railiance-infra owns the ceiling,
+   consumer conditions, current evidence and review dates. Treat the proposed
+   V0 available / V1 maximum as a starting proposal requiring current owner
+   evidence. Record acceptance in owner source before adopting the contract.
+2. **Implement and exercise the join (T03).** NetKingdom owns posture semantics
+   and the reconciler. Resolve placement from authoritative declarations,
+   compose availability across synchronous providers, and preserve
+   `satisfied`, `unsatisfied` and `unknown`. Test claims above the ceiling,
+   missing or stale evidence, and unmet recovery conditions. Exercise the
+   accepted contract against the named consumer and retain reproducible
+   declaration revisions and results before marking this task done.
+3. **Resolve classification and map it (T06).** Obtain InfoTechCanon's recorded
+   ruling separating public disclosure from synthetic provenance. Then have
+   ops-warden adopt the authoritative maturity mapping and test its consumer
+   behavior. The existing `public -> M1` suggestion remains a proposal;
+   do not alias public to synthetic or silently guess a floor.
+4. **Close on owner artifacts and consumer evidence.** Reconcile all three
+   tasks against the accepted declarations, implementation and tests; update
+   source statuses and run `statehub fix-consistency --repo net-kingdom`.
+   Mark the plan finished only when those artifacts exist.
+
+The reef and classification owner discussions can proceed independently once
+work is resumed. No cluster expansion is a prerequisite: the first useful
+result may correctly document and enforce the existing single-domain limit.
+Any subsequent runtime or admission-policy activation must follow the named
+consumer owner's rollout contract. Until then, unresolved facts remain
+`unknown`; backlog status supplies no new policy exception or permission.