## Verdict

The core disposition is sound and supported by the frozen material: reuse WM-ACT-043 as an enterprise profile with no new runtime identifier, and carry exactly one identifier-unassigned new-model candidate (Backup / Data Protection Policy). Mastership of external subjects is correctly held outside the aggregate, the tolerance/objective/commitment/outcome separation is correct, and no canonical publication, installable release or standards conformance is claimed.

**Not yet freezable.** The decision is not the problem; the artifacts are internally inconsistent in ways that change verdicts. Sixteen material defects below. Everything else — including the duplicate provider block — is presentational.

## Material defects

**1. Two competing outcome vocabularies, plus one undefined token.** The synthesis fixes six terms (`verified`, `verified-with-limitations`, `failed`, `blocked-by-dependency`, `indeterminate-insufficient-observation`, `not-attempted`); the reconciliation uses `pass`/`partial`/`blocked` and introduces `chain-recovered`, which is defined nowhere; the profile constraint names only `partial`/`blocked`/`indeterminate`. *Remediation:* declare the six-term set normative, record the mapping (`pass`→`verified`, `partial`→`verified-with-limitations`, `blocked`→`blocked-by-dependency`), and delete `chain-recovered` or restate it as the chain-scope value of the same enumeration.

**2. Objective attainment shares vocabulary with observation outcome.** In the acceptance result D is `verified` while the one-hour RPO is breached — two different assertions carried in one field, which reopens the target/outcome collapse invariant 1 forbids. *Remediation:* add a separate objective verdict set (`attained`, `breached`, `not-evaluable`) bound to the pinned objective and evidence, recorded alongside but never substituted for the observation outcome.

**3. RTO ≤ MTPD and RPO ≤ tolerable loss lack a comparability predicate.** The synthesis and profile state both rules unqualified; only the reconciliation restricts them to the same aggregate, scope and release pair. Unqualified, an objective can be "violated" against an MTPD from a different scope, degraded level or BIA release. *Remediation:* make comparability a precondition (same subject, scope qualifier, degraded level, pinned BIA release); incomparable pairs yield `not-evaluable`, not a violation and not compliance.

**4. Dangling input: maximum tolerable data loss.** The BIA release binding lists maximum tolerable disruption but no tolerable data loss, yet an invariant compares RPO against it. *Remediation:* add maximum tolerable data loss to the BIA release binding; RPO comparison against a release lacking it is `not-evaluable`.

**5. The two-identity decision is not carried into the profile.** The reconciliation requires two identities now (Backup Policy as new model; reusable Restore Verification as a WM-ACT-043-owned specification that must never profile Backup Policy), but the synthesis defers it ("may later justify its own profile after registry allocation") and the allocation holds call it "a separate boundary question". The profile candidate has no constraint for it at all. *Remediation:* add a profile constraint making the reusable Restore Verification specification an in-contour WM-ACT-043-owned object, distinct from the RestoreTest occurrence and from RecoveryEvidence, and scope the deferral strictly to cross-domain reuse outside continuity.

**6. Restore-verification criteria mastership collision.** Backup Policy `owns` "restore-verification cadence and acceptance policy", while restore verification separately pins "criteria". Two owners for acceptance criteria. *Remediation:* Backup Policy owns cadence and minimum verification requirements only; the executable criteria set belongs to the Restore Verification specification, which cites the policy version without redefining its requirements.

**7. Policy invariant imposes obligations on objects the policy excludes.** "Every backup execution and restore verification pins the effective policy version" is asserted as a Backup Policy invariant, yet both are in its `excludes` list — a mastership leak in the direction the candidate otherwise guards. *Remediation:* restate as an exposure obligation ("policy versions expose immutable, addressable version identity and content digest") and place the pinning obligation in WM-ACT-043 restore verification and in the platform backup-observation source.

**8. Recovery-order mastership is stated twice with different owners.** The synthesis makes recovery order a WM-ACT-043 derived artifact, the reconciliation binds it to a ContinuityPlan release, and the allocation candidate cites WM-XCT-037 for "dependency and recovery-order evidence". The profile also omits the requirement that exercises pin it. *Remediation:* restrict WM-XCT-037's purpose to dependency-graph mastership and source-graph version pin; state that recovery order is derived and owned by the ContinuityPlan release; add a profile constraint that every exercise and activation pins the recovery-order version and the source graph version.

**9. Bootstrap pre-provisioning and isolation crossings have no failure semantics.** Identity and key recovery are declared first-order dependencies, but nothing caps an outcome when they are pre-provisioned, stubbed or drawn from production inside the "isolated" target, and no rule says what an undeclared crossing does to the result. *Remediation:* require an enumerated isolation boundary with declared crossings; a declared crossing or pre-provisioned bootstrap dependency caps the outcome at `verified-with-limitations` and marks that dependency `not-attempted`; an undeclared crossing voids the result to `indeterminate-insufficient-observation`.

**10. Fixture representativeness is declared but never binding.** Invariant 9 requires synthetic tests to declare limits; no rule stops a non-representative fixture from supporting an RTO or minimum-service attainment claim. *Remediation:* add an invariant — attainment claims measured on non-representative fixtures are capped at `verified-with-limitations`, cannot assert RTO attainment, and must carry a declared scale ratio and divergence list.

**11. No time base for the measurements the material relies on.** RPO is defined from disruption time to recovery-point time and RTO to verified acceptance, but restore verification pins no disruption reference time, no acceptance time and no time source; the acceptance result reasons from a bare "twelve hours old". Released evidence also carries no validity window, so a past verification never expires. *Remediation:* require disruption reference time, recovery-point time, acceptance time, time source and an evidence validity window on restore verification and recovery evidence; absent any of these, the objective verdict is `not-evaluable`.

**12. No completeness rule for a published recovery claim.** The required pins are scattered across invariants with no single rule, so a claim can be published missing one. *Remediation:* add one traceability invariant enumerating the mandatory pins (BIA release, objective identity and version, plan release, recovery-order version, policy version, event identity, evidence scope and time); any missing pin yields `indeterminate-insufficient-observation`.

**13. The provider-waiver/timeout conflict is recorded but undecided.** It is the exact shape of the supplier X case and has no rule, invariant or fixture. *Remediation:* pin the hold to a decision rule — contradictory availability records for the same required dependency and window can never yield `verified`; the result is `blocked-by-dependency` if the dependency is required, otherwise `indeterminate-insufficient-observation`.

**14. Reference approval state is incomplete, and the profile lacks a publishability flag.** WM-ACT-008 and WM-ACT-042 are recorded as unapproved, but WM-XCT-037 and WM-SFT-016 appear with no status; the profile candidate has no `canonicalPublishable` field while the allocation candidate does. *Remediation:* give every reference an explicit approval status in the holds and add `"canonicalPublishable": false` to the profile candidate.

**15. PolicyVersion is under-specified and the two lifecycles can contradict.** Required fields omit approval authority and timestamp, nothing forbids two versions effective for the same protected scope over the same interval, and the aggregate lifecycle repeats `approved`/`effective`/`superseded` from the version lifecycle without a binding rule. *Remediation:* add `approvedBy` and `approvedAt` to PolicyVersion required, forbid overlapping effective versions per protected scope, and reduce the aggregate status to `active`/`suspended`/`retired` with effectiveness derived from versions.

**16. Fixture `blocked-service-chain` has a non-determinate expectation.** "Object restores *may be* verified" cannot pass or fail. *Remediation:* restate as determinate — D `verified` at object scope, chain `blocked-by-dependency`, RTO not attained, closure refused.

## Exact additional fixtures

Same format, `vercy-enterprise-allocation-fixtures/v1`, appended to `cases`:

```json
[
{"id":"outcome-vocabulary-mapping","kind":"negative","input":"Recovery evidence records outcome values pass and partial.","expect":"Rejected; only the six normative terms are accepted and pass/partial must be mapped to verified and verified-with-limitations at ingest."},
{"id":"chain-recovered-undefined","kind":"negative","input":"A chain claim uses the token chain-recovered.","expect":"Rejected; the token is undefined and must be expressed in the normative outcome enumeration at chain scope."},
{"id":"objective-verdict-vs-outcome","kind":"positive","input":"An object restore is verified at object scope while the pinned one-hour RPO is breached.","expect":"Observation outcome verified (object scope) and objective verdict breached are recorded as separate fields; neither overrides the other."},
{"id":"incomparable-rto-mtpd","kind":"negative","input":"An RTO at degraded level minimum-service is compared against an MTPD from a different scope qualifier and BIA release.","expect":"Comparison rejected as incomparable; verdict not-evaluable, neither violation nor compliance."},
{"id":"missing-tolerable-data-loss","kind":"negative","input":"RPO is checked against a BIA release that declares no maximum tolerable data loss.","expect":"Rejected; verdict not-evaluable until the BIA release carries the value."},
{"id":"schedule-interval-as-rpo-evidence","kind":"negative","input":"A fifteen-minute policy schedule interval is asserted as RPO attainment.","expect":"Rejected; the schedule interval is a feasibility input only."},
{"id":"undeclared-isolation-crossing","kind":"negative","input":"A restore test uses the production identity provider and production key custody without declaring the crossing.","expect":"Result voided to indeterminate-insufficient-observation."},
{"id":"declared-bootstrap-assumption","kind":"positive","input":"Identity, DNS and key material are pre-provisioned in the isolated target and declared as unexercised assumptions.","expect":"Outcome capped at verified-with-limitations, those bootstrap dependencies marked not-attempted, no RTO attainment claim."},
{"id":"non-representative-fixture-rto","kind":"negative","input":"RTO attainment is asserted from a one-percent-scale fixture.","expect":"Rejected; capped at verified-with-limitations with declared scale ratio and divergence list."},
{"id":"missing-time-base","kind":"negative","input":"A recovery point is described as twelve hours old with no disruption reference time, acceptance time or time source.","expect":"RPO and RTO verdicts are not-evaluable."},
{"id":"expired-evidence-window","kind":"negative","input":"A restore verification from fourteen months earlier is cited as current readiness outside its declared validity window.","expect":"Rejected; readiness is indeterminate-insufficient-observation."},
{"id":"incomplete-traceability-pins","kind":"negative","input":"A published recovery claim omits the recovery-order version and the policy version pin.","expect":"Rejected; outcome indeterminate-insufficient-observation."},
{"id":"stale-recovery-order-pin","kind":"positive","input":"An exercise pins recovery-order version 3 while the current ContinuityPlan release carries version 5.","expect":"The result remains valid only against version 3 and cannot support readiness for the current plan release."},
{"id":"conflicting-provider-records","kind":"negative","input":"A provider waiver asserts availability while a timeout record shows unavailability for the same required dependency and window.","expect":"Verified is forbidden; blocked-by-dependency if the dependency is required, otherwise indeterminate-insufficient-observation."},
{"id":"policy-owns-verification-criteria","kind":"negative","input":"A policy version redefines executable restore acceptance criteria.","expect":"Rejected; the policy states cadence and minimum requirements only and criteria remain with the Restore Verification specification."},
{"id":"restore-verification-profiles-policy","kind":"negative","input":"Restore Verification is declared a profile of Backup / Data Protection Policy.","expect":"Rejected; it is a WM-ACT-043-owned specification that references the policy version."},
{"id":"overlapping-effective-policy-versions","kind":"negative","input":"Two policy versions are effective for the same protected scope over the same interval.","expect":"Rejected."},
{"id":"policy-effective-without-effective-version","kind":"negative","input":"The policy aggregate is marked effective while no policy version is effective.","expect":"Rejected; aggregate effectiveness is derived from versions."},
{"id":"unapproved-reference-pin","kind":"negative","input":"The candidate publishes references to WM-XCT-037 and WM-SFT-016 with no recorded approval state.","expect":"Rejected until every reference carries an explicit approved or unverified status."}
]
```