# EM-FIN-07 — frozen semantic audit

## Verdict

**Conditional freeze of the decision; reject the artifacts as written.**

The adjudicated boundary survives audit and is preserved unchanged: reuse WM-POL-011 for obligation and authority assessment; reuse WM-ECO-032 for return revisions, filing attempts and acknowledgements; Tax Calculation stays an owned assertion; Tax Registration / Account stays independently identified, identifier-unassigned and **optional**; WM-ACT-052 demoted to thin case correlation; no catalogue, model or runtime identifier allocated. Nothing in the supplied evidence disproves any part of that.

The artifacts carrying that decision do not hold. Seventeen material defects follow: a missing normative invariant set, a structural dependency that makes basis assertions unreachable on the path Grok's counterexample proves must exist, no knowledge-time attribute anywhere despite dual-pin invariants, mastership leaks in the `owns` list, stale holds that misstate the evidence state, and fixtures that are not machine-checkable. All remediations are mechanical and require no further provider input.

---

## Material defects

### 1. No normative invariant set; three competing lists
Local synthesis (15), Claude (15) and Grok (16) present different, partly disjoint invariant lists, and no artifact marks one as normative. `profile-candidate.constraints` carries a sixth, shorter list. Downstream tooling has no contract to test against, and the three numberings collide (e.g. "address never derives an obligation" is local #4, Claude #3, Grok #3/#4).

**Remediation.** Emit one normative file `invariants.json` (`format: vercy-enterprise-invariants/v1`) containing exactly 22 entries: local 1–15, plus Grok 5, 13, 14, 16, plus Claude 12 ("return class is declared, never inferred") and Claude 15, deduplicated by predicate rather than wording. Each entry: `{id: "EMFIN07-INV-nn", statement, scope, fixtureIds[]}`. Require `fixtureIds.length >= 1` for every entry. Demote the three provider lists to non-normative appendices with an explicit `normative: false` field. Where wording differs, adopt the strictest formulation verbatim and record the loosened variants under `supersededWordings`.

### 2. Calculation owner set is ambiguous and internally inconsistent
Local synthesis and the profile candidate say a calculation is owned by "a return revision or an obligation assessment" — a phrase that names either two homes or three, and conflates Obligation with Assessment. Claude specifies two homes (revision, obligation) with `origin: authority` for assessment-derived values. Grok specifies exactly three (`Obligation | ReturnRevision | Assessment`) and makes exclusivity an invariant. An "exactly one owner" invariant over an ambiguous owner enum is unenforceable.

**Remediation.** Fix the enum at **two** owners, matching the preserved decision: `calculationOwnerKind ∈ {"ReturnRevision", "Obligation"}`, `calculationOwnerRef` required, exactly one. Authority-determined values are `Obligation`-owned assertions with `origin ∈ {"self-assessed","declared","estimate","authority-assessed","reassessment"}` and, when `origin == "authority-assessed"`, a required `assessmentRef` (a correlation link into WM-POL-011, not an ownership edge). Reject any record bearing more than one owner ref with `CALCULATION_MULTIPLE_OWNERS`. Strike the phrase "obligation assessment" from all artifacts; it is not a thing in this boundary.

### 3. Balance ownership contradiction, silently averaged away
Local synthesis and the profile candidate place "due components and balance snapshots" in WM-POL-011. Claude agrees. Grok places Balance as an asserted position "on Registration/Account **or** Obligation". The allocation candidate `boundary.excludes` explicitly excludes "tax obligation and balance" from Tax Registration / Account. So Grok's permitted placement is forbidden by the candidate it is reviewing, and the provider comparison reports the divergence as agreement.

**Remediation.** Resolve to the narrower reading, which both the preserved decision and the candidate's own `excludes` already require: `Balance` is an obligation-scoped, knowledge-timed asserted position mastered by WM-POL-011. Tax Registration / Account owns no balance, no due component and no aggregate position; add `"balance or due position of any kind"` to `boundary.excludes` verbatim. Retain Grok's two-sided guard as invariants: Balance is neither a second master of Assessment or Payment, nor erasable into them. Record the divergence in the comparison (see defect 14).

### 4. Basis assertions are owned by an optional root, so they vanish on the path Grok proves must exist
`allocation-candidate.boundary.owns` places "time-qualified residence, source/place and nexus basis assertions" inside Tax Registration / Account. But the same pack establishes that the account is optional (withholding-only: event, obligation and payment with no taxpayer-facing account), that "basis does not entail registration", and that the account must never be a mandatory bridge. A basis assertion owned by an absent root is unreachable — yet the withholding path still needs a source basis to qualify the obligation. This is the pack's one genuine structural break.

**Remediation.** Keep `JurisdictionalBasisAssertion` inside the same unallocated candidate's boundary but as an independently identified object with no ownership dependency on an account: `identity: ["basisAssertionId"]`; `required: ["basisKind","subjectKind","subjectRef","taxTypeRef","jurisdictionRef","authorityRef","ruleVersionRef","evidenceRefs","effectiveFrom","knowledgeTime","assertedBy"]`; `optional: ["effectiveTo","accountRef","confidence","supersedesRef"]`, with `accountRef` cardinality `0..1`. Add `subjectKind ∈ {"Taxpayer","Activity","Supply"}` and a closed constraint table: `residence → Taxpayer`; `place-of-supply → Supply`; `source → {Supply, Activity}`; `nexus → Activity`. Reject mismatches with `BASIS_SUBJECT_KIND_MISMATCH`. Set `evidenceRefs.minItems = 1` and reject `[]` with `BASIS_WITHOUT_EVIDENCE` — as specified today an empty array satisfies `required`. Restate the `owns` entry as "basis assertions, resolvable with or without an account".

### 5. Dual effective/knowledge-time pinning is mandated by every invariant list and implemented by no object
Local invariant 6, Claude invariant 5 and Grok invariant 12 all require effective **and** knowledge time. No object in the allocation candidate carries a knowledge-time field: `RegistrationRevision` has `effectiveFrom`/`effectiveTo`; `JurisdictionalBasisAssertion` has `validFrom`/`validTo`; neither has `knowledgeTime`, `recordedAt` or `assertedBy`. The stated reproducibility guarantee ("recomputation reproducible as-of any past instant") is therefore unimplementable, and two different names are used for one axis.

**Remediation.** Single vocabulary across all objects: `effectiveFrom` / `effectiveTo` for the effective axis; `knowledgeTime` for the knowledge axis; `authorityRecordedAt` where an external authority timestamp exists. Delete `validFrom`/`validTo`. Add `knowledgeTime` (required, instant, timezone-qualified, no local-time values) and `assertedBy` to `RegistrationRevision`, `JurisdictionalBasisAssertion` and every calculation, assessment-correlation and identifier record. Define reads as `as_of(effectiveInstant, knowledgeInstant)` with both arguments mandatory — no defaulting to wall clock. Reject any assertion lacking a knowledge-time pin with `MISSING_KNOWLEDGE_TIME_PIN`.

### 6. Mutable `status` on the root contradicts the effective-dated history invariant; lifecycle enum is undifferentiated
`TaxRegistrationAccount.required` includes `status`, while invariant "State changes are effective-dated and preserve history" requires state to live in the revision chain. Two writable homes for one fact guarantee divergence. The enum `["pending","registered","active","suspended","deregistered","closed"]` draws no distinction between `registered` and `active` or between `deregistered` and `closed`, offers no terminal state for a refused or withdrawn application, no reinstatement state though suspension implies resumption, and no transition table — so any sequence is legal.

**Remediation.** Move `status` out of the root into `RegistrationRevision` as `accountState` + `effectiveFrom` + `knowledgeTime`. On the root, expose `currentState` as a derived, non-writable projection of `as_of(now, now)` and mark it `derived: true`. Collapse the enum to seven states with distinct meanings: `applied`, `application-refused`, `application-withdrawn`, `active`, `suspended`, `deregistered`, `archived` — dropping `registered` (redundant with `active`) and `closed` (redundant with `deregistered`). Publish the transition table as data: `applied → {application-refused, application-withdrawn, active}`; `active → {suspended, deregistered}`; `suspended → {active, deregistered}`; `deregistered → {archived}`; `archived → {}`. Reject in-place root mutation with `IN_PLACE_STATE_MUTATION` and unlisted transitions with `ILLEGAL_STATE_TRANSITION`.

### 7. Mastership leak in `owns`; two masters declared with no precedence
`boundary.owns` claims "authority-issued identifiers", "tax type and filing frequency" and "account state" as owned facts. All three are determined by the authority; this model owns only recorded assertions about them. Separately, `identityTest.mastership` reads "competent tax authority **or** authoritative tax-registration system" — two masters, no precedence, so conflicting values have no resolution rule.

**Remediation.** Rewrite each leaking entry as an assertion with external mastership: "recorded assertion of authority-issued identifiers (master: issuing authority)", "recorded assertion of tax type and filing frequency (master: issuing authority)", "recorded assertion of account state (master: issuing authority)". Retain as genuinely owned only: the local account record identity, the revision chain, the lineage links and the basis assertions' local identities. Set `mastership: "competent tax authority"` singular, and add `recordingSources: [{kind: "authoritative-tax-registration-system", precedence: 2}]` with `precedence: 1` reserved to the authority. Conflicting values coexist as competing assertions ordered by precedence then `knowledgeTime`; silent overwrite is a defect.

### 8. Surrogate identity is minted where Grok forbids minting, and nothing gates instantiation
`TaxRegistrationAccount.identity: ["taxRegistrationAccountId"]` mints a local surrogate; Grok states "identity, when present, is authority-assigned; the model does not mint a surrogate". The candidate also specifies no precondition for creating an account, so nothing prevents the phantom root Grok's counterexample warns about (an account conjured on a withholding-only path to satisfy a join).

**Remediation.** Keep the surrogate — accounts demonstrably exist before an identifier arrives — but constrain it explicitly: mark `taxRegistrationAccountId` as `authoritative: false`, `externallyResolvable: false`, never rendered in taxpayer- or authority-facing output, never usable as a tax or legal identifier. Record `authorityIdentifier` as the only authority-facing handle. Add a required instantiation precondition, verbatim from Grok: an account record may be created only on (a) receipt of an authority-issued handle, or (b) an explicit account-opening or application event with a named authority. Reject creation without one with `PHANTOM_ACCOUNT_INSTANTIATION`. Add invariant: an obligation, taxable event and payment may coexist with zero accounts and zero return revisions.

### 9. `authorityIdentifier` has no uniqueness or time scope; one invariant constrains an actor this model cannot bind
`invariants` says "Authority-issued identifiers are scoped to authority, jurisdiction and tax type" but no uniqueness constraint or interval is specified, so identifier lookup is ambiguous. "Retired identifiers and revisions remain resolvable and are never recycled" purports to bind the issuing authority's behaviour, which this model cannot enforce; if an authority does reassign a handle, the store silently collides two account identities. Additionally `taxTypeRef` is required and single-valued on the root, which forces one account per tax type — a defensible choice, nowhere stated, and untested against a shared handle spanning two tax types.

**Remediation.** Define the identifier key as `(authorityRef, jurisdictionRef, taxTypeRef, authorityIdentifier, effectiveFrom, effectiveTo)` and require every lookup to supply an interval; reject interval-free lookup with `IDENTIFIER_LOOKUP_WITHOUT_INTERVAL`. Split the unenforceable invariant in two: (a) local rule — "this store never recycles a retired local identity or revision number"; (b) external observation — "an authority-reassigned handle yields a new account identity with a disjoint interval and `priorHandleHolderRef`". State the cardinality decision explicitly: one account record per `(authorityRef, jurisdictionRef, taxTypeRef)`; a single authority handle may therefore map to several account identities, and that is not a merge.

### 10. Lineage is expressed three ways in two directions, with no acyclicity, no change class, and an unspecified digest
The objects carry `successorRef` (forward), `supersedesRevision` (backward) and `supersedesRef` (backward) for one append-only semantic — traversal direction is ambiguous and cycles are unconstrained. Both provider studies require successors to carry "an explicit class, reason, authority and change set"; `RegistrationRevision` carries none. `contentDigest` is required with no algorithm, no canonical serialisation and no field scope, making it non-deterministic across implementations, and nothing states it is not identity — while Claude's own rule forbids canonicalising any of these facts by digest.

**Remediation.** One direction, one name: `supersedesRef` (backward, `0..1`) on every versioned object; delete `successorRef` and `supersedesRevision`; expose forward navigation as a derived index. Enforce acyclicity and single-parent (`LINEAGE_CYCLE`, `LINEAGE_FORK`). Add to `RegistrationRevision.required`: `changeClass ∈ {"correction","amendment","supersession","withdrawal","authority-initiated","administrative"}`, `changeReason`, `changeAuthorityRef`, `changeSet`. Specify the digest exactly: `contentDigest = {algorithm: "sha-256", canonicalForm: "jcs", scope: ["<explicit ordered field list>"]}`, excluding `knowledgeTime` and `contentDigest` itself; declare `identifying: false`; reject digest-keyed equality with `DIGEST_USED_AS_IDENTITY`. Make `filingFrequency` optional — a withholding or one-off registration has none, and requiring it forces a fabricated sentinel.

### 11. "At most one authority response per attempt" contradicts the pack's own response taxonomy
Claude invariant 7 states each attempt has "at most one correlated authority response", while Claude's own assessment section makes receipt, technical validity and acceptance-for-processing three distinct assertions — routinely all three against one attempt. Local synthesis is looser ("each acknowledgement correlates to an attempt") and says nothing about multiplicity of other response types. As written, a schema rejection followed by nothing else and a receipt-then-acceptance sequence cannot both be represented.

**Remediation.** Introduce `AuthorityResponse` as a separately identified WM-ECO-032 member: `identity: ["authorityResponseId"]`; `required: ["attemptRef","responseClass","authorityRecordedAt","knowledgeTime"]`; `responseClass ∈ {"receipt","schema-rejection","business-rejection","acceptance-for-processing","acknowledgement"}`; cardinality `attempt → 0..n`, `response → exactly 1 attempt`. Replace Claude invariant 7 with: "at most one response of a given `responseClass` per attempt; an attempt may carry several classes". Deterministic ordering: `authorityRecordedAt`, then `knowledgeTime`, then `authorityResponseId` ascending. Retain Grok's guard: acknowledgement is neither assessment nor notice.

### 12. Version pins are mandated against reference targets that the boundary does not provide
Every invariant list requires rule, rate, form, schema, taxonomy and code-set versions pinned to effective period and knowledge time. `boundary.references` lists only WM-POL-001 (legal rules). Rate-schedule ownership is an open hold in all three artifacts. So the calculation invariants cannot be satisfied by any reference target in the pack — a mandated constraint with no referent.

**Remediation.** Add a single `PinnedExternalVersion` reference shape usable without an allocated master: `required: ["pinKind","authorityRef","versionId","effectiveFrom","knowledgeTime","sourcePin"]`, `optional: ["effectiveTo"]`, `pinKind ∈ {"legal-rule","rate-schedule","formula","form","schema","taxonomy","code-set"}`. Add a hold stating that no master is allocated for `rate-schedule`, `formula`, `form`, `schema`, `taxonomy` or `code-set`, and that pins remain opaque references until one is. Forbid storing rate or threshold **values** in any object of this candidate (`LOCAL_RATE_COPY`) and forbid by-value rate references in calculations (`UNPINNED_RATE_REFERENCE`). This states no rates and no current law; it records only the shape of a pin.

### 13. Holds are stale; the profile carries no publishability flag; `decision: "NEW MODEL"` is consumable as an allocation
`allocation-candidate.holds` says "Independent Grok review is pending" — the Grok response is in evidence. `profile-candidate.holds` says "Independent Grok review and frozen audit remain pending" — both are now spent. The profile candidate has no `canonicalPublishable` field at all, so the pack's publication hold rests entirely on the allocation candidate. No artifact records that the frozen audit is single-run and spent, leaving the gate re-openable. And `decision: "NEW MODEL"` alongside `allocationState: "unassigned"` is a string tooling can read as an approved allocation.

**Remediation.** Replace the two stale hold strings with exactly: `"Independent Grok review received; recorded in provider-comparison."` and `"Frozen semantic audit executed once and spent; no further provider run may be requested for EM-FIN-07."` Add `"canonicalPublishable": false` and `"publicationHold": "reviewable research; no installability, conformance or publication-readiness claim"` to the profile candidate. Change `decision` to `"NEW-MODEL-CANDIDATE"` and add `"allocationApproved": false`, `"allocationGate": "registry allocation not requested; modelId and registryId remain null and may not be inferred"`, keeping `modelId: null` and `registryId: null`. Retain the hold on unresolved WM-POL-011 / WM-ECO-032 / WM-ACT-052 overlap.

### 14. Provider comparison records consensus that does not exist; scenario labels collide across artifacts
The comparison concludes Grok's contributions "sharpen the Claude boundary without changing the decision". Three of them change constraints, not emphasis: Balance placement (defect 3), the calculation owner set (defect 2), and account cardinality shifting from expected-present to genuinely optional (defect 4, the withholding path). The comparison also lists "balance" among facts both reviews separate, which conceals the disagreement. Independently, the acceptance scenarios collide: in local synthesis and Claude, `C1`/`C2` are declared calculations on `R1`/`R2` in one jurisdiction; in Grok, `C1`/`C2` are declared calculations in **different** jurisdictions (`V1`/`V2`), with the amendment producing `C1-amended`. The same labels denote different objects, and fixtures derived from "the scenario" are therefore ambiguous. The candidate name is also spelled three ways ("Tax Registration / Account", "Tax Registration/Account", "taxpayer tax registration / tax account"), which breaks slug-based fixture matching.

**Remediation.** Add a `divergences` array to the comparison with exactly three entries — balance placement, calculation owner enumeration, account optionality — each recording `claudePosition`, `grokPosition`, `adoptedResolution` and the defect id resolving it; keep "no change to the decision" only as a statement about the *decision*, not the constraints. Replace both scenarios with one canonical scenario using namespaced, collision-free fixture labels (`EMFIN07-O1`, `EMFIN07-R1`, `EMFIN07-CALC-DECL-1`, …) and forbid bare `C1`/`C2` anywhere in the pack. Fix the canonical name `TaxRegistrationAccount` (machine) / "Tax registration account" (display); forbid slash forms.

### 15. Fixtures are not machine-checkable and do not cover the invariants
`fixtures.cases` carries prose `input`/`expect` with no literal data, no identifiers, no dates, no rule versions, no expected object graph, and no rejection codes — `"Separate basis assertions retain authority, rule version, evidence and interval without implicit netting"` cannot be evaluated by a harness, and the four negative cases have no distinguishable failure modes. Coverage is absent for: the withholding-only path, account-as-mandatory-bridge, identifier arriving after account opening, identifier reassignment, single-owner calculation, equal-totals-no-merge, balance placement, WM-ACT-052 owning an amount, multiple authority responses per attempt, acknowledgement-as-assessment, knowledge-time replay, purpose-bound access, in-place state mutation, lineage cycles, digest-as-identity, basis subject-kind mismatch, empty evidence and implicit basis netting.

**Remediation.** Bump to `vercy-enterprise-allocation-fixtures/v2` with a per-case schema: `{id, kind, invariantIds[], target, fixedClock, input (literal objects only), expectKind ∈ {"accept","reject"}, assertions[], rejectCode?}`. Harness rules, stated in the file: fixed clock `2026-03-31T00:00:00Z`; no `now()`, no random, no locale- or timezone-dependent formatting; all identifiers synthetic and fixture-local; all amounts in test currency `XTS` with explicit precision; all reject codes drawn from a closed enum. Rewrite the seven existing cases into this shape — `address-creates-obligation` becomes `expectKind: "reject"`, `rejectCode: "ADDRESS_AS_OBLIGATION_GROUND"`; `legal-registration-merge` → `LEGAL_AND_TAX_REGISTRATION_MERGE`; `basis-collapse` → `BASIS_KIND_COLLAPSE`; `deregister-delete` → `HARD_DELETE_OF_CITED_HISTORY` — and add the eighteen cases below.

### 16. Profile `bases` omits a dependency its own constraints rely on; containment is listed without a ledger edge
`profile-candidate.constraints` and the local synthesis both route payments through "WM-ECO-009 transactions with the EM-FIN-03 allocation profile", and Claude's minimal model set names that pairing — but `bases` lists WM-ECO-009 alone, so the cross-contour dependency is unresolvable. `bases` also lists WM-ACT-052 with no negative constraint forbidding it to own amounts, revisions, assessments, balances or payments, though that is an explicit Grok blocker. And the pack's central unresolved contradiction — registry `parent_ids` asserting WM-POL-011 containment for WM-ECO-032 and WM-ACT-052 while the frozen relation ledger holds no tax rows — appears only as narrative prose in the holds, not as a machine-readable constraint.

**Remediation.** Add `"EM-FIN-03 allocation profile"` to `bases` with `purpose: "payment allocation to obligations"`. Add the constraint verbatim: "WM-ACT-052 owns no amount, no return or revision, no assessment, no notice, no balance and no payment; any such field is a defect." Add `"assertsContainment": false` plus the hold "registry `parent_ids` assert WM-POL-011 containment for WM-ECO-032 and WM-ACT-052; the frozen relation ledger records no tax edge; this profile asserts no containment until an approved ledger edge exists." Add separately: `entry_kind` (registry) and `entryKind` (document) are distinct axes and must not be conflated.

### 17. Privacy semantics are circular; "tax profile" names two different things
`allocation-candidate.invariants` offers "Privacy and access controls follow taxpayer and authority policy" — a constraint that defers to an unnamed policy and tests nothing. Claude's restricted-by-default, purpose-bound, tombstone-not-delete regime and Grok's "access and retention attach to Taxpayer, Registration/Account, Return Revision and Dispute, not to a collapsed profile" appear in neither machine artifact, and no field carries a classification. Separately, "tax profile" is used as a component of the obligation tuple ("authority, jurisdiction, tax profile, liable party, period") *and* as Grok's non-storing convening view that "cannot master registrations, obligations, calculations or filings" — one term, two incompatible meanings, in one pack.

**Remediation.** Replace the circular invariant with four testable ones: (a) default classification `restricted` on every object of this candidate, with `authorityIdentifier` classified `restricted-identifier`; (b) every read requires `purpose` from a closed enum plus `actorRef` and is logged with `knowledgeTime`, rejecting unbound reads with `ACCESS_WITHOUT_PURPOSE_BINDING`; (c) deletion is replaced by `deregistered → archived` plus tombstone, with prior obligations, returns and assessments remaining resolvable; (d) retention floor is `max(statutory minimum as pinned by an external reference, active legal hold)` — no statutory period asserted here, only the dependency. Attach access and retention to Taxpayer, TaxRegistrationAccount, ReturnRevision and Dispute; forbid any convening view from persisting identifiers or amounts. Eliminate the term collision: in the obligation tuple use `taxTypeRef` + `obligationClass`; reserve "TaxProfile" for the non-storing view and mark it `persists: false`, `masters: []`.

---

## Exact additional fixtures

Fixture labels below are fixture-local synthetic strings. They are not model, catalogue, registry or authority identifiers and allocate nothing.

```json
[
  {"id":"withholding-only-no-account","kind":"positive","invariantIds":["EMFIN07-INV-16"],"target":"TaxRegistrationAccount","fixedClock":"2026-03-31T00:00:00Z","input":{"taxableEvent":{"id":"FX-EVT-1","jurisdictionRef":"FX-J2","occurredAt":"2026-01-15T00:00:00Z"},"obligation":{"id":"FX-O3","master":"WM-POL-011","jurisdictionRef":"FX-J2","ruleVersionRef":"FX-RULE-7","basisAssertionRefs":["FX-BASIS-3"]},"payment":{"id":"FX-PAY-1","master":"WM-ECO-009","allocatedTo":"FX-O3","amount":{"value":"100.00","currency":"XTS"}},"taxRegistrationAccounts":[],"returnRevisions":[]},"expectKind":"accept","assertions":["accountCount == 0","returnRevisionCount == 0","FX-O3 resolves with FX-BASIS-3 and FX-RULE-7","FX-PAY-1 resolves to FX-O3 with no account traversal"]},
  {"id":"account-as-mandatory-bridge","kind":"negative","invariantIds":["EMFIN07-INV-16"],"target":"resolver","fixedClock":"2026-03-31T00:00:00Z","input":{"query":{"from":"FX-PAY-1","to":"FX-O3","path":["payment","taxRegistrationAccount","obligation"]}},"expectKind":"reject","rejectCode":"ACCOUNT_AS_MANDATORY_BRIDGE","assertions":["no path requires a TaxRegistrationAccount node"]},
  {"id":"basis-resolves-without-account","kind":"positive","invariantIds":["EMFIN07-INV-03"],"target":"JurisdictionalBasisAssertion","fixedClock":"2026-03-31T00:00:00Z","input":{"basisAssertionId":"FX-BASIS-3","basisKind":"source","subjectKind":"Supply","subjectRef":"FX-SUP-1","taxTypeRef":"FX-TT-WHT","jurisdictionRef":"FX-J2","authorityRef":"FX-AUTH-2","ruleVersionRef":"FX-RULE-7","evidenceRefs":["FX-EVD-9"],"effectiveFrom":"2026-01-01T00:00:00Z","knowledgeTime":"2026-01-20T00:00:00Z","assertedBy":"FX-ACTOR-1","accountRef":null},"expectKind":"accept","assertions":["accountRef absent is valid","basis resolves standalone"]},
  {"id":"basis-implies-registration","kind":"negative","invariantIds":["EMFIN07-INV-02","EMFIN07-INV-14"],"target":"inference","fixedClock":"2026-03-31T00:00:00Z","input":{"inference":"FX-BASIS-3 exists therefore an account must be created for FX-TAXPAYER-1 in FX-J2"},"expectKind":"reject","rejectCode":"BASIS_IMPLIES_REGISTRATION","assertions":["no account is created"]},
  {"id":"registration-implies-obligation","kind":"negative","invariantIds":["EMFIN07-INV-14"],"target":"inference","fixedClock":"2026-03-31T00:00:00Z","input":{"inference":"account FX-ACC-1 is active therefore obligation exists for every period"},"expectKind":"reject","rejectCode":"REGISTRATION_IMPLIES_OBLIGATION","assertions":["obligationCount unchanged"]},
  {"id":"identifier-assigned-after-opening","kind":"positive","invariantIds":["EMFIN07-INV-06"],"target":"TaxRegistrationAccount","fixedClock":"2026-03-31T00:00:00Z","input":{"account":{"taxRegistrationAccountId":"FX-ACC-1","authorityRef":"FX-AUTH-1","jurisdictionRef":"FX-J1","taxTypeRef":"FX-TT-A","authorityIdentifier":null},"revisions":[{"revision":1,"accountState":"applied","effectiveFrom":"2026-01-05T00:00:00Z","knowledgeTime":"2026-01-05T00:00:00Z"},{"revision":2,"accountState":"active","authorityIdentifier":"FX-HANDLE-1","effectiveFrom":"2026-01-05T00:00:00Z","knowledgeTime":"2026-02-10T00:00:00Z","supersedesRef":1}]},"expectKind":"accept","assertions":["as_of(2026-01-31,2026-01-31).authorityIdentifier == null","as_of(2026-01-31,2026-03-01).authorityIdentifier == 'FX-HANDLE-1'","revision 1 unchanged"]},
  {"id":"handle-reassigned-requires-interval","kind":"negative","invariantIds":["EMFIN07-INV-09"],"target":"resolver","fixedClock":"2026-03-31T00:00:00Z","input":{"accounts":[{"taxRegistrationAccountId":"FX-ACC-1","authorityIdentifier":"FX-HANDLE-1","effectiveFrom":"2026-01-05T00:00:00Z","effectiveTo":"2026-02-28T00:00:00Z"},{"taxRegistrationAccountId":"FX-ACC-4","authorityIdentifier":"FX-HANDLE-1","effectiveFrom":"2026-03-01T00:00:00Z","priorHandleHolderRef":"FX-ACC-1"}],"query":{"authorityIdentifier":"FX-HANDLE-1","interval":null}},"expectKind":"reject","rejectCode":"IDENTIFIER_LOOKUP_WITHOUT_INTERVAL","assertions":["query with interval 2026-01-10 resolves exactly FX-ACC-1","the two accounts never merge"]},
  {"id":"one-handle-two-tax-types","kind":"positive","invariantIds":["EMFIN07-INV-09"],"target":"TaxRegistrationAccount","fixedClock":"2026-03-31T00:00:00Z","input":{"accounts":[{"taxRegistrationAccountId":"FX-ACC-2","taxTypeRef":"FX-TT-A","authorityIdentifier":"FX-HANDLE-2"},{"taxRegistrationAccountId":"FX-ACC-3","taxTypeRef":"FX-TT-B","authorityIdentifier":"FX-HANDLE-2"}]},"expectKind":"accept","assertions":["accountCount == 2","shared handle is not a merge"]},
  {"id":"calculation-two-owners","kind":"negative","invariantIds":["EMFIN07-INV-12"],"target":"Calculation","fixedClock":"2026-03-31T00:00:00Z","input":{"calculationId":"FX-CALC-1","calculationOwnerKind":"ReturnRevision","calculationOwnerRef":"FX-R1","obligationRef":"FX-O2"},"expectKind":"reject","rejectCode":"CALCULATION_MULTIPLE_OWNERS","assertions":["exactly one owner ref permitted"]},
  {"id":"authority-calculation-home","kind":"positive","invariantIds":["EMFIN07-INV-12"],"target":"Calculation","fixedClock":"2026-03-31T00:00:00Z","input":{"calculationId":"FX-CALC-ASSD-1","calculationOwnerKind":"Obligation","calculationOwnerRef":"FX-O2","origin":"authority-assessed","assessmentRef":"FX-S1","ruleVersionRef":"FX-RULE-4","ratePinRef":"FX-PIN-3","rounding":"half-up-2","amount":{"value":"1234.56","currency":"XTS"},"knowledgeTime":"2026-03-10T00:00:00Z"},"expectKind":"accept","assertions":["no Assessment-owned calculation root is created","assessmentRef is correlation, not ownership"]},
  {"id":"equal-totals-no-merge","kind":"negative","invariantIds":["EMFIN07-INV-13"],"target":"Calculation","fixedClock":"2026-03-31T00:00:00Z","input":{"declared":{"calculationId":"FX-CALC-DECL-1","calculationOwnerKind":"ReturnRevision","calculationOwnerRef":"FX-R2","amount":{"value":"1234.56","currency":"XTS"}},"assessed":{"calculationId":"FX-CALC-ASSD-1","calculationOwnerKind":"Obligation","calculationOwnerRef":"FX-O2","amount":{"value":"1234.56","currency":"XTS"}},"operation":"merge-on-equal-total"},"expectKind":"reject","rejectCode":"CROSS_HOME_CALCULATION_MERGE","assertions":["both calculations remain separately resolvable","correlation link permitted, equality not"]},
  {"id":"balance-not-account-owned","kind":"negative","invariantIds":["EMFIN07-INV-01","EMFIN07-INV-10"],"target":"TaxRegistrationAccount","fixedClock":"2026-03-31T00:00:00Z","input":{"taxRegistrationAccountId":"FX-ACC-1","balancePosition":{"value":"500.00","currency":"XTS","asOfKnowledgeTime":"2026-03-31T00:00:00Z"}},"expectKind":"reject","rejectCode":"BALANCE_NOT_ACCOUNT_OWNED","assertions":["same balance position attached to FX-O2 under WM-POL-011 is accepted","balance is neither a second master of assessment or payment nor erased into them"]},
  {"id":"case-owns-economic-fact","kind":"negative","invariantIds":["EMFIN07-INV-11"],"target":"WM-ACT-052 case profile","fixedClock":"2026-03-31T00:00:00Z","input":{"caseId":"FX-PC-2","correlates":["FX-A2","FX-S1","FX-N1"],"assessedAmount":{"value":"1234.56","currency":"XTS"}},"expectKind":"reject","rejectCode":"CASE_OWNS_ECONOMIC_FACT","assertions":["case without assessedAmount is accepted","case owns only identifier, scope tuple, orchestration state, deadlines and typed links"]},
  {"id":"multiple-authority-responses-per-attempt","kind":"positive","invariantIds":["EMFIN07-INV-09","EMFIN07-INV-11"],"target":"AuthorityResponse","fixedClock":"2026-03-31T00:00:00Z","input":{"attempts":[{"id":"FX-A1","revisionRef":"FX-R1","responses":[{"id":"FX-RESP-1","responseClass":"receipt","authorityRecordedAt":"2026-02-01T09:00:00Z","knowledgeTime":"2026-02-01T09:05:00Z"},{"id":"FX-RESP-2","responseClass":"schema-rejection","authorityRecordedAt":"2026-02-01T09:02:00Z","knowledgeTime":"2026-02-01T09:05:00Z"}]},{"id":"FX-A2","revisionRef":"FX-R1","responses":[{"id":"FX-RESP-3","responseClass":"receipt","authorityRecordedAt":"2026-02-03T09:00:00Z","knowledgeTime":"2026-02-03T09:01:00Z"},{"id":"FX-RESP-4","responseClass":"acceptance-for-processing","authorityRecordedAt":"2026-02-03T09:10:00Z","knowledgeTime":"2026-02-03T09:11:00Z"},{"id":"FX-RESP-5","responseClass":"acknowledgement","authorityRecordedAt":"2026-02-03T09:20:00Z","knowledgeTime":"2026-02-03T09:21:00Z"}]}]},"expectKind":"accept","assertions":["FX-R1 has 2 attempts","FX-A2 has 3 responses of distinct classes","ordering is (authorityRecordedAt, knowledgeTime, responseId) ascending","a second receipt on FX-A2 is rejected as DUPLICATE_RESPONSE_CLASS"]},
  {"id":"acknowledgement-as-assessment","kind":"negative","invariantIds":["EMFIN07-INV-11"],"target":"inference","fixedClock":"2026-03-31T00:00:00Z","input":{"inference":"FX-RESP-5 acknowledgement establishes assessed liability for FX-O2"},"expectKind":"reject","rejectCode":"ACK_TREATED_AS_ASSESSMENT","assertions":["receipt, validity, acceptance, assessment, payment and finality imply none of each other"]},
  {"id":"knowledge-time-replay","kind":"positive","invariantIds":["EMFIN07-INV-06"],"target":"Calculation","fixedClock":"2026-03-31T00:00:00Z","input":{"calculationId":"FX-CALC-DECL-1","pins":[{"pinKind":"legal-rule","versionId":"FX-RULE-4","effectiveFrom":"2026-01-01T00:00:00Z","knowledgeTime":"2026-01-02T00:00:00Z","sourcePin":"FX-SRC-1"},{"pinKind":"rate-schedule","versionId":"FX-PIN-3","effectiveFrom":"2026-01-01T00:00:00Z","knowledgeTime":"2026-01-02T00:00:00Z","sourcePin":"FX-SRC-2"}],"replay":{"effectiveInstant":"2026-02-15T00:00:00Z","knowledgeInstant":"2026-02-20T00:00:00Z"}},"expectKind":"accept","assertions":["replay output is byte-identical across runs","replay with knowledgeInstant omitted is rejected as MISSING_KNOWLEDGE_TIME_PIN","no rate value is stored locally"]},
  {"id":"in-place-state-mutation","kind":"negative","invariantIds":["EMFIN07-INV-07","EMFIN07-INV-08"],"target":"TaxRegistrationAccount","fixedClock":"2026-03-31T00:00:00Z","input":{"operation":"set","target":"FX-ACC-1.currentState","value":"suspended"},"expectKind":"reject","rejectCode":"IN_PLACE_STATE_MUTATION","assertions":["a new RegistrationRevision with accountState 'suspended', effectiveFrom and knowledgeTime is accepted","currentState is derived and non-writable","transition active -> suspended is in the published table"]},
  {"id":"lineage-cycle-and-digest-identity","kind":"negative","invariantIds":["EMFIN07-INV-08"],"target":"RegistrationRevision","fixedClock":"2026-03-31T00:00:00Z","input":{"revisions":[{"revision":3,"supersedesRef":4,"contentDigest":"FX-DIGEST-1","knowledgeTime":"2026-03-01T00:00:00Z"},{"revision":4,"supersedesRef":3,"contentDigest":"FX-DIGEST-1","knowledgeTime":"2026-03-02T00:00:00Z"}],"operation":"dedupe-on-digest"},"expectKind":"reject","rejectCode":"LINEAGE_CYCLE","assertions":["dedupe-on-digest is separately rejected as DIGEST_USED_AS_IDENTITY","digest algorithm sha-256 with canonical form jcs over the declared field scope"]},
  {"id":"implicit-basis-netting","kind":"negative","invariantIds":["EMFIN07-INV-05"],"target":"JurisdictionalBasisAssertion","fixedClock":"2026-03-31T00:00:00Z","input":{"bases":[{"basisAssertionId":"FX-BASIS-1","basisKind":"residence","jurisdictionRef":"FX-J1"},{"basisAssertionId":"FX-BASIS-2","basisKind":"nexus","jurisdictionRef":"FX-J2"}],"operation":"suppress FX-BASIS-2 because FX-BASIS-1 exists"},"expectKind":"reject","rejectCode":"IMPLICIT_BASIS_NETTING","assertions":["both bases remain active and unranked","any relief or allocation must be a separate assertion with its own basis, authority and rule version"]},
  {"id":"access-without-purpose-binding","kind":"negative","invariantIds":["EMFIN07-INV-15"],"target":"access control","fixedClock":"2026-03-31T00:00:00Z","input":{"read":{"field":"FX-ACC-1.authorityIdentifier","actorRef":null,"purpose":null}},"expectKind":"reject","rejectCode":"ACCESS_WITHOUT_PURPOSE_BINDING","assertions":["default classification is restricted","authorityIdentifier is restricted-identifier","a read with actorRef and an enumerated purpose is accepted and logged with knowledgeTime"]}
]
```

---

## Freeze decision

**Freeze the decision. Do not freeze the artifacts.**

The EM-FIN-07 boundary is frozen as adjudicated and is not reopened: WM-POL-011 for obligation and authority assessment; WM-ECO-032 for return revisions, filing attempts and acknowledgements; Tax Calculation as an owned assertion with a two-value owner enum; Tax Registration / Account independently identified, identifier-unassigned, optional and never a mandatory bridge; WM-ACT-052 thin case correlation only; no catalogue, model or runtime identifier allocated, and none inferable from this audit.

The allocation candidate, profile candidate, fixtures and provider comparison do not pass. Defects 1–17 are mechanical corrections to those four files and require no additional provider input; defect 4 (basis assertions unreachable when the optional account is absent) and defect 5 (no knowledge-time attribute on any object) are the two that break the model rather than its description, and must be applied before the pack is cited as a boundary. After remediation the contour stands as reviewable research on single-provider, non-canonical bases: no installability, conformance, completeness or publication-readiness claim, and publication remains held by the unallocated Tax Registration / Account candidate, the three-way aggregate overlap, the registry `parent_ids` / empty relation-ledger contradiction, and unresolved rate-schedule, jurisdiction and tax-type ownership.

This audit is spent. No further provider run for EM-FIN-07.

---

I can write this to `research/enterprise/runs/em-fin-07/` alongside the existing `frozen-audit.prompt.md` if you want it persisted — say the word and I'll check the naming convention used by the earlier reconciled contours first.