Codex Resonance
/
Codex Commons
/
🧪
CC-EXP-NEXT-01 — Codex Commons Next Candidate Test Set v0.1
/
♻️
CC-EXP-CHANGE-01 — Change, Supersession & Revalidation Generality Test v0.1
♻️

CC-EXP-CHANGE-01 — Change, Supersession & Revalidation Generality Test v0.1

Experiment ID: CC-EXP-CHANGE-01

Version: 0.1

Date: 19 September 2026

Candidate area: Change / Supersession / Revalidation

Standing: INTERNAL — EXECUTED GENERALITY / DECOMPOSITION / PRIOR-ART REDUCTION. NO COMMONS ADMISSION OR PUBLICATION AUTHORISED.

Question

Do effective periods, supersession, invalidation and revalidation require a fourth Commons semantic profile, or should RRAP/QMAP/Assessment Assertion reuse established provenance/time/version semantics plus common lifecycle guidance?

Executive result

PASS WITH REJECTION OF A FOURTH PROFILE.

The recurring need is real, but it is cross-cutting lifecycle metadata/governance rather than a distinct semantic object profile.

Recommendation:

Create Commons Lifecycle & Revalidation Guidance, not a new candidate semantic profile.

Core distinctions

Newer ≠ Superseding

A later artefact/version does not automatically supersede an earlier one.

Superseded ≠ Invalid

An artefact may be superseded for one purpose but remain historically valid/applicable elsewhere.

Expired ≠ False

Expiry limits current applicability; it does not rewrite historical standing.

Changed Source ≠ Automatically Invalidated Dependent

Change may trigger revalidation; effect depends on dependency/materiality.

Revalidation Trigger ≠ Revalidation Result

Trigger creates need for review/assessment, not automatic failure.

Generality probes

G1 — Framework version update

New framework version may trigger QMAP reassessment.

PASS.

G2 — Vendor capability change

Changed vendor claim may trigger V2/V3/assessment review without erasing prior evidence.

PASS.

G3 — Regulation amendment

Old rule remains historically authoritative for prior period; applicability changes by effective date/jurisdiction.

PASS.

G4 — Schema migration

v2 may supersede v1 for new writes while v1 remains valid for historical data.

PASS.

G5 — QMAP mapping supersession

New mapping assertion may supersede old for a purpose/version while preserving lineage.

PASS.

G6 — RRAP role change

Representation may move from proposed design context to implemented role through explicit process; historical assignments remain.

PASS.

G7 — Assessment expiry

Assessment may require revalidation after time/source/subject change; old finding remains historical.

PASS.

G8 — Authority source change

Change triggers applicability review; does not silently transfer authority to a new representation.

PASS.

Hard cases

  • two versions concurrently applicable → supported via scope/time;
  • one purpose superseded, another retained → purpose-relative supersession;
  • source changes immaterially → trigger may resolve no revalidation needed;
  • evidence becomes stale → current reliance changes; history preserved;
  • withdrawn basis → future reliance changes; historical assessment retained;
  • revalidation fails → new assessment/finding, old record preserved;
  • revalidation succeeds → new standing/effective interval, no history rewrite;
  • jurisdiction-specific change → applicability scoped.

PASS.

Prior-art reduction

Established standards/vocabularies already provide much of:

  • provenance/revision/derivation;
  • temporal intervals;
  • version identifiers;
  • validity/effective dates;
  • supersession/replacement relations;
  • change histories.

Do not mint a Commons lifecycle ontology unless a later concrete gap is proven.

Commons lifecycle guidance candidate

All Commons profiles should support, where material:

  1. identity/version;
  2. effective_from / effective_to;
  3. supersedes / superseded_by;
  4. invalidated/withdrawn qualification where domain semantics permit;
  5. revalidation_trigger;
  6. last_reviewed / assessment reference where relevant;
  7. applicability scope;
  8. historical reconstructability.

Exact predicates should reuse established vocabularies.

Revalidation model

Change Event / Trigger
        │
        ▼
Impact / Materiality Review
        │
        ├── no material effect → retain standing
        │
        └── material effect
                ▼
           Revalidation
                ▼
        New Assertion / Finding /
        Role / Mapping Standing
                │
                ▼
        preserve prior history

Revalidation is a process/activity, not a semantic status.

Relationship to profiles

RRAP: role assignments may have effective scope/time and supersession.

QMAP: mappings may be versioned/superseded/revalidated.

Assessment Assertion: findings may expire, be invalidated or require reassessment.

No profile should independently invent incompatible lifecycle semantics.

Decision

CC-EXP-CHANGE-01 — PASS; FOURTH PROFILE REJECTED.

  1. Preserve change/revalidation as cross-cutting Commons lifecycle guidance.
  2. Reuse provenance/time/version standards.
  3. Keep history reconstructable.
  4. Do not equate newer with superseding, expired with false, or trigger with failed validation.
  5. No admission package needed.
  6. Advance to Evidence / Assertion Standing decomposition.

Linked