# EM-TEC-09 — Frozen semantic audit

Single frozen audit. No tools, no browsing, no new study. Admitted evidence: the initial Claude study, the local synthesis, the visible Grok response up to its truncation point, and the seven appended candidate artifacts. All Grok hidden reasoning and any sources it reached are excluded. Nothing after `Rule-to-standard reference cardinality is not` is inferred; the blocker list below is auditor-supplied, not Grok-supplied.

## 1. Verdict

**Decision: sound, frozen as stated. Artifacts: not acceptance-ready — 16 material defects, all closable by deterministic edit without new evidence.**

The settled boundary survives audit on every point put to it:

- Technology, Technology Adoption and Architecture Exception each pass an independent identity test. Technology is an abstract capability class with no producer, digest or support contract; Technology Adoption is an organization-scoped standing state that persists after the decision that authorized it and can change without a new one; Architecture Exception has a subject, owner, authority and expiry that are none of the standard's. All three correctly remain identifier-unassigned.
- Architecture Exception as waiver master is correct and is the strongest settlement in the Grok pass. A grant can precede the assessment that cites it and outlast a failed retest, so it cannot be an assessment property; it bounds permission to operate rather than accepting residual risk, so it cannot be a risk-acceptance property.
- Renewal as a new grant is correct and load-bearing: an edited expiry destroys the audit trail of who authorized which period.
- Architecture Standard over WM-KNW-012 with WM-KNW-013 rules by reference is correct; WM-KNW-012 already owns work/expression identity, issuing authority, applicability scope, precedence, separated in-force/efficacy intervals and supersession.
- Conformance Assessment over WM-ACT-034 is correct; pinned criteria binding, tailoring with not-applicable justification, per-criterion evidence and aggregation are already owned.
- ADR as reuse of WM-KNW-010 / WM-ACT-024 / WM-REC-010 is correct; an ADR causes adoption transitions, expressions and grants and is referenced by them, and is none of them.
- The required separations hold: technology vs product/release/package/deployment; upstream lifecycle vs vendor support vs local adoption; adoption vs conformance; exception vs assessment vs nonconformity vs risk acceptance.
- Rejecting WM-REC-005 as standard master is correct; a registry of models and ontologies is not a normative standards artifact regardless of its registry name.
- No runtime or model identifier is allocated. Correct, and must stay so.

What fails is the **artifact layer**: the three allocation candidates introduce four identifiers not present in any admitted evidence, ship vocabularies that contradict their own invariants, and leave the one question Grok was cut off mid-sentence on unanswered. The two profiles have no objects, no invariants, no fixtures and no validation policy at all. No canonical completeness, installability or publication readiness is claimed by this audit.

## 2. Material defects and deterministic remediation

**D1 — Prior fixtures do not satisfy the required fixture schema.**
All 18 prior cases carry only `id`, `kind`, `input`, `expect`. The schema requires `id`, `target`, `kind`, `input`, `expect`, `violates`, `closesDefect`, and `expectedCode` on every negative.
*Remediation:* re-emit all 18 with `target` set to the containing file's `candidateName` verbatim, `violates` set to the exact invariant string from that candidate, `closesDefect` set to `"D1"`, and these exact codes on the nine negatives: `product-collapse` → `EMTEC09.TECH.PRODUCT_CONFLATION`; `deployment-state` → `EMTEC09.TECH.DEPLOYMENT_STATE_LEAK`; `license-inheritance` → `EMTEC09.TECH.LICENSE_INHERITANCE`; `implicit-conformance` → `EMTEC09.ADOPT.CONFORMANCE_IMPLIED`; `floating-scheme` → `EMTEC09.ADOPT.STAGE_SCHEME_UNPINNED`; `silent-transition` → `EMTEC09.ADOPT.SILENT_TRANSITION`; `assessment-rewrite` → `EMTEC09.EXC.OUTCOME_REWRITE`; `unbounded` → `EMTEC09.EXC.UNBOUNDED_GRANT`; `risk-collapse` → `EMTEC09.EXC.RISK_ACCEPTANCE_COLLAPSE`. Change no `input` or `expect` text.

**D2 — Four reference identifiers appear in no admitted evidence.**
The Technology candidate references `WM-SFT-009` and `WM-SFT-010`; Technology Adoption references `WM-ORG-001`; Architecture Exception references `WM-KNW-015`. The study and synthesis name only WM-SFT-001, WM-SFT-002, WM-SFT-007, WM-KNW-010, WM-KNW-012, WM-KNW-013, WM-ACT-024, WM-ACT-034, WM-REC-005, WM-REC-006, WM-REC-010. These four are unadmitted and must be treated as invented until a registry read says otherwise.
*Remediation:* delete all four. Replace the Technology release/deployment references with `WM-SFT-001` (release lineage sits inside the product boundary per the study) and `WM-SFT-002` carrying the verbatim hold `"Deployment boundary is asserted on prior Enterprise research only and is unverified here."`. Add `WM-SFT-007` for the component/package boundary. Replace `WM-KNW-015` with a residual-risk reference to the `WM-KNW-010 / WM-ACT-024 / WM-REC-010` triad. Replace the Technology Adoption organization reference with the literal unresolved referent `{"target": null, "targetName": "Organization", "allocationState": "unassigned", "purpose": "Organization scope"}` and never substitute a guessed identifier.

**D3 — Deployment mastership contradiction, and vendor support is not excluded from Technology.**
The Technology candidate assigns the deployment boundary to `WM-SFT-010`, contradicting the study's mastership table, which assigns deployed system/application to WM-SFT-002. Separately, `excludes` omits vendor support status, which Technology Adoption's `excludes` does carry — so nothing stops an end-of-support date landing on the Technology record, defeating the three-axis separation.
*Remediation:* apply D2's substitution; add `"vendor support status"` and `"end-of-support date"` to Technology's `excludes`. Note that after D2 strikes two of Technology's four references, substitution is mandatory, not optional: without it the candidate falls to two references and fails its own `minimumReferences: 3`.

**D4 — Exception-to-standard-expression cardinality is contradictory, and rule-to-standard cardinality is unstated.**
The Exception object pins a single `standardVersionRef` with a plural `ruleRefs`, and asserts `"Each exception pins one exact standard expression."` The Claude study requires derogated rules `"possibly spanning several standards"`. These cannot both hold. Grok's sentence on reference cardinality is truncated and supplies nothing. No artifact states rule-to-expression cardinality in either direction.
*Remediation:* settle, as auditor, in favour of the singular pin, because a grant spanning expressions cannot expire or be revoked per-expression without splitting identity anyway. Constrain every member of `ruleRefs` to resolve under the one pinned `standardVersionRef`; require a derogation spanning two standards to be recorded as two grants sharing `subjectRef` and `scope`, linked by a new optional `coGrantRefs` array, with `renewalOfRef` reserved for renewal only. Add to the Architecture Standard profile the exact cardinality statement: `"One standard expression references zero or more WM-KNW-013 rule identities; one rule identity may be referenced by zero or more expressions across standards; the reference is many-to-many and non-owning."`

**D5 — Technology `status` conflates taxonomy state with upstream lifecycle, and upstream assertions have nowhere to record provenance.**
`independentLifecycle` mixes record states (`proposed`, `recognized`, `superseded`, `retired`) with community-asserted upstream states (`active`, `deprecated`, `obsolete`), and the object exposes one `status` field. The boundary owns `"upstream lifecycle assertions"` and the invariant says `"Upstream lifecycle is separately sourced."` No field carries the asserting party or observation time the study requires, so that invariant is unenforceable.
*Remediation:* split `independentLifecycle` into `recordLifecycle: ["proposed","recognized","active","deprecated","superseded","retired"]` governing the catalogue entry only. Replace `status` with required `taxonomyStatus` and add repeatable optional `upstreamLifecycleAssertions[]`, each requiring `assertedState`, `assertedBy`, `observedAt`, `sourceRef`. Delete `obsolete` from the record lifecycle; it is an upstream assertion value. Add the invariant `"An upstream lifecycle assertion without asserting party and observation time is not recorded and the upstream state remains unknown."`

**D6 — Technology Adoption ships an unschemed stage vocabulary it forbids itself.**
`independentLifecycle: ["proposed","trial","approved","preferred","restricted","deprecated","prohibited","retired"]` is a radar stage vocabulary. Invariant 2 requires `"Stage pins a named scheme and version"`, and both the study and synthesis hold that no stage scheme exists in this dossier and that one must never be assumed. The candidate asserts the prohibition and then violates it.
*Remediation:* replace `independentLifecycle` with the episode record lifecycle `["draft","effective","superseded","retired"]`, which enumerates no stage values. All stage values resolve only through `stageSchemeVersionRef`. Add the invariant `"No stage value is enumerated in this candidate; stage values resolve only from the pinned stage scheme version, and the record lifecycle and the stage vocabulary are disjoint."`

**D7 — `renewed` in the Exception lifecycle contradicts renewal as a new grant.**
`independentLifecycle` contains `renewed` as a state of the grant itself. If a grant can enter `renewed`, renewal is an extension of one identity, which both the settled boundary and Grok invariant 11 forbid.
*Remediation:* delete `renewed` from `independentLifecycle`, leaving `["requested","reviewed","granted","effective","expired","revoked","closed"]`. The predecessor terminates in `expired` or `revoked`; the successor is a new identity carrying `renewalOfRef`. Add the invariant `"No grant enters a renewed state and no effective grant's validUntil is edited; renewal is a distinct identity referencing its predecessor."`

**D8 — No non-overlap and no no-back-dating constraints on episodes or grants.**
Technology Adoption says transitions `"append successor episodes"` but nothing forbids two effective episodes for one organization/technology/scope triple, so the as-of resolution both the study and synthesis require is ambiguous. Architecture Exception has no constraint matching Grok's explicit `"No back-dating."`, so a renewal can be dated into the predecessor's window and produce two concurrent grants over the same rule and subject.
*Remediation:* add to Technology Adoption: `"For one organization, technology and scope, at most one episode is effective at any instant, and a successor episode's validFrom equals the predecessor's validTo."` Add to Architecture Exception: `"A grant's validFrom is not earlier than its authorizing decision time, and a renewal's validFrom is not earlier than its predecessor's effective end; concurrent effective grants over the same subject, scope and rule are rejected."`

**D9 — Three settled Grok invariants are carried in no artifact.**
Concurrent assessments against different standard versions for one subject; recommended-technology use as evidence for at most one rule; a grant that may precede or outlast the assessment citing it. All three are explicitly settled in the visible Grok text and appear in no candidate or profile constraint.
*Remediation:* add to the profile constraints, verbatim: `"One subject may hold concurrent conformance assessments against different standard expressions, and neither supersedes the other by existing."` and `"Use of a recommended technology is evidence for at most one rule and never aggregates to a whole-system conformance claim."` Add to Architecture Exception: `"A grant's validity is independent of any assessment; it may exist before the first citing assessment and remains effective after a failed retest until expiry or revocation."`

**D10 — Three-party distinctness is weakened to two parties.**
Architecture Exception asserts only `"Granting authority and owner are distinct roles."` The study requires granting authority ≠ assessing party ≠ subject owner, and separately logs that WM-ACT-034 has no assessor competence or impartiality function — so the assessing party is unconstrained on both sides.
*Remediation:* replace that invariant with `"Granting authority, assessing party and subject owner are three distinct parties, and no party holds two of these roles on one grant."` Add the assessing-party reference to the Exception object as required `assessingPartyRef` where an assessment is cited. Add to the profile the hold `"WM-ACT-034 carries no assessor competence or impartiality function; three-party distinctness is enforced at the Architecture Exception boundary only and remains unenforced on the assessment side."`

**D11 — Waiver-mastership settlement is not reflected in the reused bases.**
The study found WM-KNW-012 owning registered derogations and WM-KNW-013 carrying a `waived` outcome value plus its own exception finding — three models touching waiver. Grok settled mastership on Architecture Exception, but no artifact records what happens to the two base-side waiver surfaces, so an implementation may still master a waiver there.
*Remediation:* add to the profile constraints: `"WM-KNW-012 registered derogations and the WM-KNW-013 waived outcome value are non-mastering projections; each must resolve to exactly one Architecture Exception grant and neither may be authored independently of one."` and `"A criterion outcome is never set to waived because a grant exists; the outcome remains violated and the grant is cited alongside it."`

**D12 — Architecture Standard and Conformance Assessment have no objects, invariants, fixtures or validation policy.**
The single profile candidate carries five prose constraints, no `objects`, no `invariants`, no `holds`, no `canonicalPublishable`, and no fixture file or validation policy exists for either profile. Two of the five settled candidates are therefore entirely unvalidated.
*Remediation:* add a `vercy-allocation-validation/v1` policy for profiles requiring, at minimum, declared profiled base, non-ownership statement, three positive and three negative fixtures per profile, and `newRuntimeId: false`. Add the profile invariants `"The standard expression stores rule references only and never rule text, and never mints a rule identity."`, `"A rule reference set changes only by issuing a successor expression version; the in-force expression is never edited."`, and `"The assessment pins one standard expression at one version and one pinned subject state."` Fixtures are supplied below.

**D13 — Effective conformance status has no declared owner or derivation.**
Both the study and synthesis make `"nonconformant with exception in force"` load-bearing, and both insist the assessment outcome is unchanged. No artifact says which model holds that composed status or that it is derived, so it will be persisted as an assessment field and will drift at expiry.
*Remediation:* add to the profile: `"Effective conformance status is a derived read-only projection with no identity and no master; it is recomputed from the pinned assessment plus the grants effective at the queried instant, is never persisted on an assessment or a grant, and is never cited as an assessment outcome."`

**D14 — `decisionRef` and the grant decision reference pin the record plane only.**
Technology Adoption requires `decisionRef` and references `WM-REC-010` as `"Authorizing decision"`; Architecture Exception references `WM-REC-010` as `"Grant decision"`. The settled ADR is the full triad, so a WM-REC-010-only pin loses the rationale and the authorized occurrence.
*Remediation:* restate both references as `{"target":"WM-KNW-010 / WM-ACT-024 / WM-REC-010","purpose":"Authorizing decision triad"}` and add the invariant `"A decision reference resolves the rationale, the authorized occurrence and the issued record; a reference that resolves only the issued record is incomplete."`

**D15 — Technology `ownerRef` is ambiguous and implies authority.**
`ownerRef` is required on a catalogue entity that the study says has `"no authority, no alternatives and no approver"`, and the name does not distinguish taxonomy steward from producer from accountable system owner.
*Remediation:* rename to `taxonomyStewardRef` and add `"The taxonomy steward is never a producer, vendor or subject owner, and confers no authority to adopt, assess, grant or waive."`

**D16 — The validation policies cannot detect D1 or D2.**
All three policies are byte-identical and require `minimumFixtures: 3` against actual counts of 6, assert `requiresPositiveAndNegativeFixtures: true` with no per-polarity minimum, and impose no fixture-field schema and no reference-admissibility check. The profile candidate additionally lacks `canonicalPublishable` and the four holds its three sibling candidates carry, so it asserts constraints over non-canonical bases with no recorded hold.
*Remediation:* set `minimumPositiveFixtures: 3`, `minimumNegativeFixtures: 3`, `requiredFixtureFields: ["id","target","kind","input","expect","violates","closesDefect"]`, `requiredNegativeFixtureFields: ["expectedCode"]`, and `referenceTargetsMustBeEvidenced: true`. Add `"canonicalPublishable": false` and the four verbatim holds to the profile candidate.

## 3. Additional fixtures

`violates` names the invariant under test: for a negative, the invariant the input would breach; for a positive, the invariant that would be breached if `expect` failed. Quoted strings are exact candidate text; strings marked `(added:)` are the remediation-defined invariants above.

```json
[
  {"id":"tech-upstream-assertion-sourced","target":"Technology","kind":"positive","input":"An upstream community asserts deprecation, naming the asserting body and the observation instant.","expect":"The assertion is retained with asserting party and observation time while taxonomyStatus is unchanged.","violates":"Upstream lifecycle is separately sourced.","closesDefect":"D5"},
  {"id":"tech-status-conflation","target":"Technology","kind":"negative","input":"A single status field is set to obsolete from an upstream notice and then read as the taxonomy state.","expect":"The conflation is rejected; taxonomy status and upstream assertion are separate fields.","violates":"(added:) Taxonomy status and upstream lifecycle assertions are separately recorded.","closesDefect":"D5","expectedCode":"EMTEC09.TECH.STATUS_CONFLATION"},
  {"id":"tech-upstream-unsourced","target":"Technology","kind":"negative","input":"An upstream lifecycle change is recorded with no asserting party and no observation time.","expect":"The assertion is rejected and the upstream state remains unknown.","violates":"(added:) An upstream lifecycle assertion without asserting party and observation time is not recorded and the upstream state remains unknown.","closesDefect":"D5","expectedCode":"EMTEC09.TECH.UPSTREAM_UNSOURCED"},
  {"id":"tech-vendor-support-excluded","target":"Technology","kind":"negative","input":"A vendor end-of-support date is recorded on the technology record.","expect":"The placement is rejected; vendor support status is outside the technology boundary.","violates":"(added:) Vendor support status and end-of-support date are excluded from Technology.","closesDefect":"D3","expectedCode":"EMTEC09.TECH.SUPPORT_ON_TECHNOLOGY"},
  {"id":"tech-deployment-reference-mastered","target":"Technology","kind":"positive","input":"A technology is mapped to a deployed instance through the operator-side deployment boundary.","expect":"The reference resolves to the evidenced deployment boundary and carries the prior-research-only hold.","violates":"Technology and deployment remain distinct.","closesDefect":"D3"},
  {"id":"tech-unevidenced-reference","target":"Technology","kind":"negative","input":"A boundary reference names a registry identifier that appears in no admitted evidence.","expect":"The reference is rejected as an unevidenced identifier.","violates":"Registry allocation is pending and no identifier may be guessed.","closesDefect":"D2","expectedCode":"EMTEC09.REF.UNEVIDENCED_IDENTIFIER"},
  {"id":"tech-steward-no-authority","target":"Technology","kind":"negative","input":"The taxonomy steward approves an adoption transition and signs an exception grant.","expect":"Both acts are rejected; the steward holds no governance authority.","violates":"(added:) The taxonomy steward is never a producer, vendor or subject owner, and confers no authority to adopt, assess, grant or waive.","closesDefect":"D15","expectedCode":"EMTEC09.TECH.STEWARD_AUTHORITY_CLAIM"},
  {"id":"tech-steward-named","target":"Technology","kind":"positive","input":"A technology record names its taxonomy steward and no approver.","expect":"The steward is retained as a catalogue role with no authority implied.","violates":"(added:) The taxonomy steward is never a producer, vendor or subject owner, and confers no authority to adopt, assess, grant or waive.","closesDefect":"D15"},
  {"id":"adopt-stage-from-scheme","target":"Technology Adoption","kind":"positive","input":"An adoption episode carries a stage value resolved from a pinned stage scheme version.","expect":"The stage resolves through the pinned scheme and no stage value originates in the candidate.","violates":"Stage pins a named scheme and version.","closesDefect":"D6"},
  {"id":"adopt-enumerated-stage","target":"Technology Adoption","kind":"negative","input":"A stage value is taken from the candidate's own lifecycle list instead of a pinned scheme version.","expect":"The stage is rejected; no stage vocabulary is assumed by the candidate.","violates":"(added:) No stage value is enumerated in this candidate; stage values resolve only from the pinned stage scheme version.","closesDefect":"D6","expectedCode":"EMTEC09.ADOPT.STAGE_VOCABULARY_UNSCHEMED"},
  {"id":"adopt-record-lifecycle-disjoint","target":"Technology Adoption","kind":"positive","input":"An episode moves from draft to effective to superseded while its stage value is unchanged.","expect":"Record lifecycle and stage vocabulary move independently and remain disjoint.","violates":"(added:) The record lifecycle and the stage vocabulary are disjoint.","closesDefect":"D6"},
  {"id":"adopt-non-overlap","target":"Technology Adoption","kind":"positive","input":"A successor episode for one organization, technology and scope starts exactly at the predecessor's end, and an as-of query is issued inside each window.","expect":"Each query returns exactly one effective stage.","violates":"(added:) For one organization, technology and scope, at most one episode is effective at any instant.","closesDefect":"D8"},
  {"id":"adopt-overlap","target":"Technology Adoption","kind":"negative","input":"Two episodes for the same organization, technology and scope hold overlapping effective intervals.","expect":"The second episode is rejected; as-of resolution must be unambiguous.","violates":"(added:) For one organization, technology and scope, at most one episode is effective at any instant.","closesDefect":"D8","expectedCode":"EMTEC09.ADOPT.EPISODE_OVERLAP"},
  {"id":"adopt-backdated","target":"Technology Adoption","kind":"negative","input":"An episode's validFrom precedes the time of its authorizing decision.","expect":"The episode is rejected; effect never precedes authorization.","violates":"Each transition requires authority and decision.","closesDefect":"D8","expectedCode":"EMTEC09.ADOPT.BACKDATED_EFFECT"},
  {"id":"adopt-decision-triad","target":"Technology Adoption","kind":"positive","input":"An episode's decision reference is dereferenced for audit.","expect":"Rationale, authorized occurrence and issued record all resolve.","violates":"(added:) A decision reference resolves the rationale, the authorized occurrence and the issued record.","closesDefect":"D14"},
  {"id":"adopt-record-plane-only","target":"Technology Adoption","kind":"negative","input":"An episode's decision reference resolves only an issued record, with no rationale and no occurrence.","expect":"The reference is rejected as an incomplete decision triad.","violates":"(added:) A reference that resolves only the issued record is incomplete.","closesDefect":"D14","expectedCode":"EMTEC09.DECISION.TRIAD_INCOMPLETE"},
  {"id":"adopt-organization-guessed","target":"Technology Adoption","kind":"negative","input":"The organization reference is filled with a plausible but unallocated registry identifier.","expect":"The reference is rejected and must remain an explicit unassigned external referent.","violates":"Registry allocation is pending and no identifier may be guessed.","closesDefect":"D2","expectedCode":"EMTEC09.REF.GUESSED_IDENTIFIER"},
  {"id":"exc-single-expression","target":"Architecture Exception","kind":"positive","input":"A grant pins one standard expression and enumerates three rules, all of which resolve under that expression.","expect":"The grant is accepted with every derogated rule resolving under the single pinned expression.","violates":"Each exception pins one exact standard expression.","closesDefect":"D4"},
  {"id":"exc-cross-standard-rules","target":"Architecture Exception","kind":"negative","input":"One grant enumerates rules belonging to two different standard expressions.","expect":"The grant is rejected; separate grants are required per standard expression.","violates":"Each exception pins one exact standard expression.","closesDefect":"D4","expectedCode":"EMTEC09.EXC.EXPRESSION_FANOUT"},
  {"id":"exc-sibling-grants","target":"Architecture Exception","kind":"positive","input":"A derogation spanning two standards is recorded as two grants sharing subject and scope and linked as co-grants.","expect":"Both grants are accepted, each independently expirable and revocable.","violates":"(added:) A derogation spanning two standard expressions is recorded as co-grants, not as one grant.","closesDefect":"D4"},
  {"id":"exc-renewal-new-identity","target":"Architecture Exception","kind":"positive","input":"An expiring grant is renewed with tightened conditions.","expect":"A new grant identity is created with renewalOfRef, and the predecessor closes as expired.","violates":"Renewal creates a new grant.","closesDefect":"D7"},
  {"id":"exc-renewed-state","target":"Architecture Exception","kind":"negative","input":"The predecessor grant is set to a renewed state and its validUntil is moved forward.","expect":"The edit is rejected; renewal is never an extension of one identity.","violates":"(added:) No grant enters a renewed state and no effective grant's validUntil is edited.","closesDefect":"D7","expectedCode":"EMTEC09.EXC.RENEWAL_AS_EXTENSION"},
  {"id":"exc-renewal-backdated","target":"Architecture Exception","kind":"negative","input":"A renewal's validFrom is dated before its predecessor's effective end, over the same subject, scope and rule.","expect":"The renewal is rejected; concurrent effective grants over the same rule are not permitted.","violates":"(added:) A renewal's validFrom is not earlier than its predecessor's effective end.","closesDefect":"D8","expectedCode":"EMTEC09.EXC.GRANT_OVERLAP"},
  {"id":"exc-three-party","target":"Architecture Exception","kind":"positive","input":"A grant names a granting authority, an assessing party and a subject owner that are three different parties.","expect":"The grant is accepted with three-party distinctness recorded.","violates":"(added:) Granting authority, assessing party and subject owner are three distinct parties.","closesDefect":"D10"},
  {"id":"exc-assessor-grants","target":"Architecture Exception","kind":"negative","input":"The party that performed the conformance assessment also grants the exception.","expect":"The grant is rejected for role collapse.","violates":"(added:) No party holds two of these roles on one grant.","closesDefect":"D10","expectedCode":"EMTEC09.EXC.PARTY_COLLAPSE"},
  {"id":"exc-precedes-assessment","target":"Architecture Exception","kind":"positive","input":"A grant is issued before any assessment cites it, and a later retest fails the derogated rule.","expect":"The grant remains effective until expiry or revocation, unaffected by the failed retest.","violates":"(added:) A grant's validity is independent of any assessment.","closesDefect":"D9"},
  {"id":"exc-assessment-dependency","target":"Architecture Exception","kind":"negative","input":"A grant is voided on the grounds that no assessment cites it.","expect":"The voiding is rejected; grant validity does not depend on a citing assessment.","violates":"(added:) A grant's validity is independent of any assessment.","closesDefect":"D9","expectedCode":"EMTEC09.EXC.ASSESSMENT_DEPENDENCY"},
  {"id":"exc-residual-risk-separate","target":"Architecture Exception","kind":"positive","input":"Residual risk for a derogation is accepted through a separate decision under the rationale, occurrence and issued-record triad.","expect":"The acceptance is referenced by the grant and stored outside it.","violates":"Residual-risk acceptance requires a separate decision.","closesDefect":"D2"},
  {"id":"std-rule-cardinality","target":"Architecture Standard","kind":"positive","input":"One standard expression references nine rule identities, and one of those rules is also referenced by an expression of a different standard.","expect":"The many-to-many non-owning reference is accepted in both directions.","violates":"(added:) The expression-to-rule reference is many-to-many and non-owning.","closesDefect":"D4"},
  {"id":"std-rule-ownership","target":"Architecture Standard","kind":"negative","input":"A standard expression stores the normative rule text inline and mints a local rule identity.","expect":"Both are rejected; rule identity and text stay with the referenced rule boundary.","violates":"(added:) The standard expression stores rule references only and never rule text, and never mints a rule identity.","closesDefect":"D12","expectedCode":"EMTEC09.STD.RULE_OWNERSHIP"},
  {"id":"std-silent-swap","target":"Architecture Standard","kind":"negative","input":"A rule reference is replaced inside an in-force expression without issuing a successor version.","expect":"The edit is rejected; a prior assessment must stay reproducible.","violates":"(added:) A rule reference set changes only by issuing a successor expression version.","closesDefect":"D12","expectedCode":"EMTEC09.STD.SILENT_RULE_SWAP"},
  {"id":"std-derogation-mastership","target":"Architecture Standard","kind":"negative","input":"A registered derogation is authored directly on a standard expression and treated as the waiver of record.","expect":"The authoring is rejected; the waiver master is the exception grant.","violates":"(added:) Registered derogations are non-mastering projections and may not be authored independently of a grant.","closesDefect":"D11","expectedCode":"EMTEC09.WAIVER.MASTERSHIP_COLLAPSE"},
  {"id":"std-derogation-projection","target":"Architecture Standard","kind":"positive","input":"A registered derogation slot on a standard expression is dereferenced.","expect":"It resolves to exactly one exception grant as a non-mastering projection.","violates":"(added:) Each registered derogation must resolve to exactly one Architecture Exception grant.","closesDefect":"D11"},
  {"id":"ca-concurrent-versions","target":"Conformance Assessment","kind":"positive","input":"One application holds a live assessment against standard expression v1.0 and another against v2.0.","expect":"Both assessments remain valid and neither supersedes the other by existing.","violates":"(added:) One subject may hold concurrent conformance assessments against different standard expressions.","closesDefect":"D9"},
  {"id":"ca-waived-outcome","target":"Conformance Assessment","kind":"negative","input":"A criterion outcome is changed from violated to waived because an exception grant is in force.","expect":"The change is rejected; the outcome stays violated and the grant is cited alongside it.","violates":"(added:) A criterion outcome is never set to waived because a grant exists.","closesDefect":"D11","expectedCode":"EMTEC09.WAIVER.OUTCOME_COERCION"},
  {"id":"ca-recommended-language","target":"Conformance Assessment","kind":"negative","input":"Use of a technology recommended by the standard is cited as whole-system conformance.","expect":"The claim is rejected; such use is evidence for at most one rule.","violates":"(added:) Use of a recommended technology is evidence for at most one rule and never aggregates to a whole-system conformance claim.","closesDefect":"D9","expectedCode":"EMTEC09.CA.EVIDENCE_OVERREACH"},
  {"id":"ca-effective-status-derived","target":"Conformance Assessment","kind":"positive","input":"An effective status of nonconformant with exception in force is requested at an instant inside the grant window, then at an instant after expiry.","expect":"Both answers are recomputed from the pinned assessment plus grants effective at each instant, and the assessment outcome is identical in both.","violates":"(added:) Effective conformance status is a derived read-only projection with no identity and no master.","closesDefect":"D13"},
  {"id":"ca-effective-status-persisted","target":"Conformance Assessment","kind":"negative","input":"Effective conformance status is written onto the assessment as a stored field.","expect":"The write is rejected; the projection is never persisted.","violates":"(added:) Effective conformance status is never persisted on an assessment or a grant.","closesDefect":"D13","expectedCode":"EMTEC09.CA.EFFECTIVE_STATUS_PERSISTED"},
  {"id":"profile-holds-carried","target":"Enterprise Technology Standards and Exceptions","kind":"positive","input":"The profile candidate is validated for non-canonical base disclosure.","expect":"canonicalPublishable is false and the four pending holds are carried verbatim.","violates":"Base specifications and approved relations remain incomplete.","closesDefect":"D16"},
  {"id":"policy-rejects-fieldless-fixture","target":"EM-TEC-09 validation policy","kind":"negative","input":"A fixture omits violates and closesDefect, and a negative fixture omits expectedCode.","expect":"Both fixtures are rejected by the policy's required-field check.","violates":"(added:) requiredFixtureFields and requiredNegativeFixtureFields are enforced.","closesDefect":"D1","expectedCode":"EMTEC09.FIXTURE.SCHEMA_INCOMPLETE"},
  {"id":"policy-polarity-minimum","target":"EM-TEC-09 validation policy","kind":"positive","input":"A candidate presents four positive and two negative fixtures.","expect":"The candidate fails the three-negative minimum rather than passing on total count alone.","violates":"(added:) minimumPositiveFixtures and minimumNegativeFixtures are each three.","closesDefect":"D16"},
  {"id":"prior-fixtures-migrated","target":"EM-TEC-09 fixture set","kind":"positive","input":"The eighteen prior fixtures are re-emitted under the required schema with assigned codes and unchanged input and expect text.","expect":"All eighteen validate, and no prior input or expect wording has changed.","violates":"(added:) requiredFixtureFields are enforced on every fixture, prior and additional.","closesDefect":"D1"}
]
```

## 4. Final fixture counts

| Set | Positive | Negative | Total |
|---|---|---|---|
| Prior (Technology 6, Technology Adoption 6, Architecture Exception 6) | 9 | 9 | 18 |
| Additional (this audit) | 20 | 22 | 42 |
| **Total** | **29** | **31** | **60** |

Prior by candidate: Technology 3 positive / 3 negative; Technology Adoption 3 / 3; Architecture Exception 3 / 3.
Additional by target: Technology 3 / 5; Technology Adoption 4 / 4; Architecture Exception 5 / 4; Architecture Standard 2 / 3; Conformance Assessment 2 / 2; profile candidate 1 / 0; validation policy 1 / 1; fixture set 1 / 0. Architecture Standard and Conformance Assessment each reach the three-positive, three-negative minimum only once D12's counts are read together with D4's cardinality fixture, which is filed under Architecture Standard.

## 5. Freeze decision

**Boundary: FROZEN. Artifacts: NOT FROZEN — amend under the sixteen remediations above, then freeze without further review.**

The semantic decision is frozen exactly as put to audit: three identifier-unassigned roots; Architecture Exception as waiver master with renewal as a new grant; Architecture Standard profiling WM-KNW-012 and referencing WM-KNW-013; Conformance Assessment profiling WM-ACT-034; ADR reusing the triad; technology distinct from product, release, package, deployment, lifecycle, support and local adoption; adoption and conformance independent; exception distinct from assessment, nonconformity and risk acceptance; no identifier allocated. No part of it is reopened and no rerun is requested or performed.

The artifact layer is held open only for edits that need no evidence beyond what is already admitted. All sixteen remediations are mechanical: deletions, renames, field splits, verbatim constraint insertions, and the 18-fixture migration. The one question that was genuinely unsettled — exception-to-expression and rule-to-expression cardinality, left mid-sentence by the provider truncation — is settled here as auditor under D4 rather than deferred, since deferring it would require the rerun this audit is forbidden to request.

Three things stay explicitly unresolved and must travel forward as holds, not as defects this audit can close: registry allocation for all three roots, which no reasoning can supply; the deployment-boundary assignment, which rests on prior Enterprise research only and is unverified here; and the absence of any adoption-stage scheme in this dossier, which keeps every stage value a dangling pinned reference until a scheme exists. Grok's blocker enumeration was cut off, so the blocker list in this audit is mine and should not be read as a complete intersection of both passes.

No canonical completeness, installability, package conversion or publication readiness is claimed.