Define versioned diagnostic identities and compatibility

CHANGELOG.md

@@ -8,6 +8,14 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). Version
 
 ## [Unreleased]
 
+### Changed
+
+- Define versioned diagnostic identities for canonical ACTIONs, schema shapes,
+  supported view forms and assertion-gap reports. Preserve schedule-view codes
+  and retired CODEX identities. The new ACTION numeric lower bounds target the
+  next major release, **7.0.0**, with a [compatibility and migration contract](migrations/6.0-to-7.0/);
+  current release pins are unchanged.
+
 ## [6.0.0] — Unreleased
 
 Bump category: **MAJOR**. Knowledge supersession now enforces errors on admitted

migrations/6.0-to-7.0/README.md

@@ -0,0 +1,137 @@
+# Diagnostic compatibility — methodology 6.0 → 7.0
+
+This migration contract is for catalogue maintainers and validator implementers.
+The target **7.0.0** is unreleased; this document does not change the current
+release or any manifest pin. It defines the next-major boundary for the ACTION
+numeric restrictions in [24-action.md](../../notations/elements/24-action.md)
+§6–6.1. Adding diagnostic identities for already-invalid structures does not
+itself change their validity. Rejecting previously accepted numbers does.
+
+## Compatibility and migration
+
+Through 6.x, ACTION `score` is an integer without a published lower bound;
+cost and effort fields are numbers without a published lower bound. From 7.0.0,
+negative `duration`, `duration_days`, `labor_cost`, `resources_cost`, `effort`,
+and `score` produce `ACTION-011` errors. Zero remains valid, fractions remain
+valid for the number fields, and fractional scores remain schema errors.
+`sort` is not covered. Existing `duration_days` inputs remain supported; neither
+that alias nor the accepted `Strategic Initiative` value is removed here.
+
+Before upgrading:
+
+1. Preserve the catalogue revision and original diagnostic output, including
+   the validator version. Check the six named fields on canonical and supported
+   inline ACTION records. Do not apply the check to every numeric field.
+2. Review each negative value with its author. Correct genuine data errors from
+   evidence. If a negative score or cost intentionally conveys a signed measure,
+   preserve that meaning in an appropriately named `extensions` field and remove
+   or replace the canonical value only after review. Do not clamp, take absolute
+   values, or silently discard the source value.
+3. Reconcile `duration_days` with `duration` in the declared schedule units.
+   Where both are supplied, preserve the original values in the review record,
+   choose the intended canonical duration, and remove the redundant alias only
+   after confirming equivalence. No automatic conversion is safe without units.
+4. Validate against the target contract, review visible warnings and unsupported
+   forms, and update the manifest only when adopting a released 7.0.0 validator
+   and methodology. The per-file `spec_version` is informational, not a switch
+   enabling new errors in an older catalogue.
+
+## Historical emissions and normalisation
+
+The following profile covers **canonical ACTION emissions in Studio source
+revision `4b39c67b790d92c542286934c5275d8e2f4d8f47`**, not
+alternative meanings for the schedule-view codes. A historical record must
+retain its original fields. Only a record with the named source revision and
+canonical ACTION element context may acquire the indicated successor as an
+additional normalised field. Other versions require their own explicit mapping.
+
+| Legacy canonical ACTION emission | Successor | Severity | Meaning |
+|---|---|---|---|
+| `ACT-005` | `ACTION-007` | warning | Unresolved parent or predecessor |
+| `ACT-006` | `ACTION-008` | error | Predecessor cycle |
+| `ACT-007` | `ACTION-009` | error | Self predecessor |
+| `ACT-008` | `ACTION-010` | error | Invalid/reversed planned dates |
+| `ACT-009` | `ACTION-011` | error | Negative value in the six named numeric fields |
+
+In the published schedule specification, `ACT-005` remains an **error** for an unresolved scoped GOAL;
+`ACT-006` an invalid type filter; `ACT-007` invalid/duplicate working days;
+`ACT-008` invalid holiday dates; and `ACT-009` the missing schedule-anchor
+**warning**. Their complete table, including scheduling advisories, remains in
+[07-action.md §6](../../notations/views/diagrams/07-action.md#6-validation-rules).
+`ACTION-006` stays reserved and inactive.
+
+Do not confuse that normative table with the observed schedule implementation at
+`4b39c67b790d92c542286934c5275d8e2f4d8f47`: it emits `ACT-009` as a numeric
+**error**, and `ACT-019` for the missing-anchor **warning**. That numeric emission
+is a collision requiring a tooling correction, not a new meaning for the published
+`ACT-009`. The canonical mapping above cannot be applied to schedule records.
+
+`CODEX-003` remains retired: its historical codex v0.1 meaning was typed-ID
+resolution inside `applies_to`. It must not be globally aliased to `CODEX-002`.
+A tool's incorrect use of it for missing jurisdiction/effective date is corrected
+to `CODEX-002` only when the stored context identifies that missing-field check.
+
+## Positive and rejecting examples
+
+Each row is a mutation of an otherwise valid document in the named form;
+“passes” means this rule does not fire, not that all catalogue checks pass.
+Consumers can use these pairs to check diagnostic meaning independently of code
+spelling. All errors must identify the affected field; warnings remain visible.
+
+| Rule | Positive example | Rejecting / advisory example |
+|---|---|---|
+| `ACTION-007` | Omitted root parent; predecessor resolves in catalogue | `parent: ACTION-MISSING-1` with no such ACTION → warning |
+| `ACTION-008` | ACTION-1 precedes ACTION-2 only | ACTION-1 and ACTION-2 each name the other as predecessor → error |
+| `ACTION-009` | ACTION-1 has `predecessors: []` | ACTION-1 has `predecessors: [ACTION-1]` → error |
+| `ACTION-010` | Both dates `2026-09-24`; either date absent | `2026-02-30`, or end `2026-09-23` before start `2026-09-24` → error |
+| `ACTION-011` | Each of the six fields separately set to `0`; number fields `0.5`; score `2` | Each field separately set to `-1` → error in 7.0.0; negative score/cost not newly rejected on 6.x pins |
+| `SCHEMA_INVALID` | ACTION `score: 2`, `predecessors: []` | `score: 2.5`, `score: "2"`, or `predecessors: {}` → error with notation and field/type context |
+| `CODEX-002` | REGULATION has jurisdiction and effective date | Omit either required field → error; never retired `CODEX-003` |
+| `AC-001` | Object `action_card` with valid metadata | Remove `action_card` → error |
+| `AC-002` | `action_card.id: ACTION_CARD-1` | Remove only `action_card.id`, or set it to an invalid ID → error |
+| `APP-002` | Inline `applications_catalogue` has required metadata and `applications: []` | Remove catalogue or replace applications array with an object → error |
+| `CMAP-002` | Inline `capability_map` has required metadata and `capabilities: []` | Remove map or replace capabilities array with an object → error |
+| `FGCA-004` | Inline arrays of objects, including `goals: []` with no dangling references; changes omitted with changes layer off | Inline `goals: {}` or missing goals → error; nonempty enforcement belongs to `DGCA-004`, not this shape code |
+| `PMAP-002` | Inline `process_map: {id: PMAP-1, name: Example, updated_at: "2026-09-24", groups: []}` | Remove `process_map`, or replace `groups` with an object → error; not a products rule |
+| `SCN-002` | Historical inline `scenario: {id: SCENARIO-1, name: Example, status: Draft}` | Omit `scenario`, its `id`, `name` or `status` → error; not a projection configuration rule |
+| `GAP-REQ-NO-ASSERT` | ASSERTION.about targets the REQUIREMENT | No targeting ASSERTION, even with a VERIFICATION → advisory warning, not noncompliance |
+
+The gap report may also observe absent targeting assertions for CONSTRAINTs,
+but must state that ASSERTION does not support those targets in v1. It must not
+require creating an invalid assertion. Shape rows describe only their owning
+supported forms. Any unsupported form remains explicitly unvalidated, with
+`NOTATION-SKIP-001` and strict-mode failure under CONTRACT §18; neither migration
+nor code normalisation can turn it into a clean validation result.
+
+
+## Known implementation gaps at the compared revision
+
+The source revision above and its locally packaged CLI 2.9.4 / diagrams 1.13.3
+were compared with the example mutations. These observations are revision-bound;
+they are not claims about a subsequently published or installed validator.
+
+- Canonical ACTION still emits the legacy codes above. Negative score/cost is
+  rejected even under a 6.0.0 pin; the specified 7.0.0 compatibility boundary is
+  not implemented. Fractional/string scores and object-valued predecessors pass
+  the canonical path without the required schema finding. Schedule validation
+  accepts fractional scores, rejects string scores with the colliding `ACT-009`,
+  and can fail on object-valued predecessors without a JSON diagnostic.
+- `duration ?? duration_days` determines scheduling precedence, but both fields
+  are independently checked. Different positive values coexist; a negative alias
+  still fails beside a positive canonical value. No equality or integer check may
+  be inferred from the absence of a finding.
+- Missing codex jurisdiction/effective date still emits retired `CODEX-003`;
+  correction to `CODEX-002` remains required.
+- Inline DGCA empty arrays pass the historical `FGCA-004` shape check. A dangling
+  reference may independently fail `FGCA-011`; remove it when testing emptiness
+  alone. This does not satisfy the stronger `DGCA-004` nonempty requirement.
+- Products catalogue shape failures emit `PROD-002`, not `PMAP-002`. That runtime
+  predicate is broader than the published products `PROD-002` ID rule. Keep the
+  discrepancy explicit rather than silently redefining the published identity.
+- Products and scenarios projection documents are sent through inline predicates
+  in the compared runtime. They fail for absent `products_catalogue` or `scenario`
+  instead of receiving the required unsupported-form report. `SCN-002` must not be
+  described as evidence that projection `view.name` was checked.
+
+These gaps require validator follow-through. The contract and examples do not
+claim runtime conformance, and a source merge alone does not close the gaps.

notations/CONTRACT.md

@@ -1351,3 +1351,32 @@ notation is unsupported by that tool version. Require the latter's path and
 Missing headers, parse failures, and read failures must remain visible in the
 accounting. These checks exercise the validator; a specification inventory alone
 is not evidence that the implementation conforms.
+
+
+### 18.6 Shared schema diagnostics
+
+| Rule | Severity | Description |
+|---|---|---|
+| `SCHEMA_INVALID` | error | A parsed value violates the selected notation and supported form's schema shape or type: for example, a mapping is expected but a list is supplied, a collection member has the wrong type, or a required schema field is missing without a more specific rule. Include file path, notation, form, field path (with array index where relevant), expected shape/type and actual shape/type. |
+
+Use a specific published code when one covers the same defect; do not emit a
+second generic finding for that defect. Independent findings remain visible.
+An invalid YAML document is a parse failure, not a successful schema validation.
+Select the document form before validating it: a projection does not inherit
+legacy inline collections or headers. An unsupported form is unvalidated under
+§18.2, with `NOTATION-SKIP-001`; it is never a clean result merely because the
+validator cannot check it. A missing implementation does not redefine the schema.
+
+For example, `predecessors: {id: ACTION-1}` in an ACTION fails with field
+`predecessors`, expected array, actual object; `predecessors: []` passes that
+shape check. Neither example establishes the result of unrelated rules.
+
+### 18.7 Versioned diagnostic identity
+
+A stored diagnostic retains its original code, meaning, severity, notation,
+form, methodology version and emitting tool version. A consumer may show a
+normalised successor alongside it, but MUST NOT rewrite the original history.
+An alias requires that complete scope: `ACT-005` alone is never an alias for
+`ACTION-007`, because the schedule-view `ACT-005` remains a goal-resolution
+error. See the [6.0 → 7.0 migration contract](../migrations/6.0-to-7.0/) for the
+canonical-element corrections and their compatibility boundary.

notations/elements/14-codex.md

@@ -379,7 +379,7 @@ One artefact per file, named by its canonical ID. Examples:
 | `CODEX-005` | info | A `type: REGULATION` artefact does not declare `monitoring_needed:`. The field SHOULD be explicit so downstream consumers (and scanner agents) know whether the source is static or live — see §3.4. Info severity, not warning, because some legacy artefacts predate the field; new REGULATION artefacts SHOULD set it. |
 | `CODEX-006` | info | A `type: PRINCIPLE` artefact does not declare `established_by` (§4.1). Info severity — a record without one is admissible; the absence is a review finding for whoever admits it, not a defect the validator blocks on. |
 
-Rule code `CODEX-003` was retired alongside `applies_to`; the code is reserved and is not reassigned.
+Rule code `CODEX-003` was retired alongside `applies_to`; the code is reserved and is not reassigned. Missing `jurisdiction` or `effective_date` where §6 requires them is always `CODEX-002` (error), never `CODEX-003`. For example, a REGULATION with both fields passes this required-field check; omitting either fails. A PRINCIPLE does not require either field.
 
 ---
 

notations/elements/15-requirement.md

@@ -324,6 +324,7 @@ A `REQUIREMENT` records *what the design must do*; a `NEED` ([`ELEMENT_PRIMITIVE
 | `REQ-006` | error | `kind` is present but its value is not one of `functional \| quality` (§2.6). |
 | `REQ-PARENT-001` | error | In the draft requirement-chain extension, a present inline `parent` does not resolve to an admitted REQUIREMENT. Union cycle diagnostics are specified by `REL-009` / `REL-010` in Relations §5. |
 | `REQ-SERVES-001` | error | `serves` is present but does not resolve to an admitted `NEED` in canon ([`ELEMENT_PRIMITIVES.md`](../ELEMENT_PRIMITIVES.md) §7.28). |
+| `GAP-REQ-NO-ASSERT` | warning | In a gap report, a REQUIREMENT or CONSTRAINT has no targeting ASSERTION (`about` equals its ID) in the declared catalogue. Advisory absence of a recorded claim only: not missing VERIFICATION, not evidence of noncompliance. A targeting assertion suppresses this observation regardless of its claimed result; its own validity is checked separately. |
 | `REQ-COVERAGE-001` | warning | A REQUIREMENT has no ASSERTION targeting it — no file under `canon/assertions/` carries `about: <this REQ id>`. Surfaces a compliance gap: the obligation exists in the model but the organisation makes no recorded claim about whether any subject satisfies it. The rule is `warning` rather than `error` because a newly admitted REQUIREMENT legitimately has no assertion yet. Cross-cutting — fires on the REQUIREMENT but is computed by scanning the assertions catalogue. |
 | `REQ-VERIF-COVERAGE-001` | warning | A REQUIREMENT has no admitted `VERIFICATION` targeting it — no file under `canon/verifications/` carries `verifies: <this REQ id>` ([27-verification.md](27-verification.md) §2). The engineering verification analogue of `REQ-COVERAGE-001`: the ASSERTION and VERIFICATION catalogues are independent ([27-verification.md](27-verification.md) §4), so a REQUIREMENT may carry compliance coverage with no verification evidence, or vice versa. `warning`, not `error`, for the same reason as `REQ-COVERAGE-001` — a newly admitted REQUIREMENT legitimately has no verification yet, and a purely compliance-origin REQUIREMENT may never accrue one. Cross-cutting — fires on the REQUIREMENT but is computed by scanning the verifications catalogue. |
 | `REQ-VERIF-COVERAGE-002` | warning | A REQUIREMENT has one or more admitted `VERIFICATION`s targeting it, but none has reached `outcome: pass` or `outcome: fail` — every verification against it is still `not_yet_run` or `inconclusive` ([27-verification.md](27-verification.md) §3). The trace link exists but has not closed. Distinct from, and mutually exclusive with, `REQ-VERIF-COVERAGE-001` by construction. Cross-cutting, same computation basis. |
@@ -333,6 +334,16 @@ The shared lifecycle (`LIFECYCLE-001..004`, [CONTRACT.md](../CONTRACT.md) §7.3)
 
 ---
 
+
+`GAP-REQ-NO-ASSERT` is a report observation, not an expansion of ASSERTION's
+permitted target types. CONSTRAINT coverage by ASSERTION remains unsupported
+in v1; the report must disclose that limitation rather than require an invalid
+assertion to silence the warning. REQUIREMENT assertion coverage and verification
+coverage are independent. A REQUIREMENT with only a VERIFICATION still receives
+this warning; one with a targeting ASSERTION does not. Preserve the existing
+`REQ-COVERAGE-001` history and report context; do not globally rename it.
+
+
 ## 5. Evolution
 
 **Landed (2026-08-27, STANDARD codex TYPE):**