Codex Resonance
/
Codex Commons
/
🧪
CC-EXP-NEXT-01 — Codex Commons Next Candidate Test Set v0.1
/
🧪
CC-EXP-C05-CONF-01 — Conformance / Acceptance Boundary — Decomposition & Generality Test v0.1
🧪

CC-EXP-C05-CONF-01 — Conformance / Acceptance Boundary — Decomposition & Generality Test v0.1

Experiment ID: CC-EXP-C05-CONF-01

Version: 0.1

Date: 19 September 2026

Candidate area: Conformance / Acceptance Boundary

Standing: INTERNAL — EXECUTED DECOMPOSITION / GENERALITY / HOSTILE TEST. NO COMMONS ADMISSION OR PUBLICATION AUTHORISED.

Question

Can Codex Commons define a reusable cross-domain semantic profile around conformance without collapsing:

constraint/reference → assessment → finding → conformance → acceptance → authority → runtime admissibility?

Executive result

PASS WITH STRONG DECOMPOSITION — THE REUSABLE CORE IS AN ASSESSMENT ASSERTION, NOT A MONOLITHIC CONFORMANCE PROFILE.

The tested pattern is:

These downstream standings remain independent.

Core distinctions

Assessment ≠ Conformance

An assessment may find conformance, non-conformance, partial/conditional conformance, insufficient evidence or not-applicable.

Conformance ≠ Acceptance

An organisation may accept a non-conforming implementation under exception/waiver, or decline a conforming item for other reasons.

Acceptance ≠ Authority

Acceptance by one governance body does not establish authority for unrelated propositions/actions.

Conformance ≠ Runtime Admissibility

A conformant design/implementation may still be inadmissible for a specific action/context.

Certification ≠ Conformance itself

Certification is an externally/institutionally governed status/credential based on a process; do not collapse it into the finding.

Candidate atomic semantic unit

Assessment Assertion: a first-class assertion stating the result of assessing a declared subject/aspect against an explicit assessment basis, under a declared method/scope/time/provenance.

This resembles QMAP structurally but addresses evaluation rather than relationship mapping.

Minimum candidate fields

  1. assessment_assertion_id
  2. subject_ref
  3. subject_aspect/scope
  4. assessment_basis_ref
  5. assessment_basis_version/profile
  6. assessment_outcome
  7. assessment_provenance

Required when material:

  1. assessment method/procedure;
  2. assessor/agent;
  3. assessment time/effective interval;
  4. evidence refs;
  5. environment/jurisdiction;
  6. qualification/limitations.

Optional/linked:

  1. conformance claim ref;
  2. acceptance decision ref;
  3. exception/waiver ref;
  4. conflict/other assessment refs;
  5. supersession/revalidation trigger.

Outcome vocabulary warning

Do not prematurely mint universal outcomes.

Candidate generic categories for testing only:

  • CONFORMS
  • DOES_NOT_CONFORM
  • PARTIALLY_CONFORMS
  • CONDITIONALLY_CONFORMS
  • INSUFFICIENT_EVIDENCE
  • NOT_APPLICABLE
  • INDETERMINATE

Domains may already define exact outcome semantics.

Generality tests

G1 — Software schema

Subject: data/API instance.

Basis: schema/profile.

Activity: validation.

Finding: conforms/violations.

Acceptance by application owner remains separate.

PASS.

G2 — Cybersecurity

Subject: implemented control.

Basis: security requirement/control profile.

Activity: evidence review/test.

Finding: effective/non-effective/conformant/non-conformant depending regime.

Risk acceptance may permit residual non-conformance.

STRONG PASS.

G3 — Building

Subject: building/system.

Basis: code/design/inspection requirement.

Finding from inspection does not itself equal occupancy permission/certification unless applicable authority/process grants it.

PASS.

G4 — Regulatory compliance

Subject: customer control/process.

Basis: applicable obligation.

Assessment finding does not itself establish a legal determination.

PASS WITH AUTHORITY GUARDRAIL.

G5 — Data contract

Subject: data product/output.

Basis: contract/schema/quality requirement.

Validation may establish technical conformance for declared version/time.

Operational acceptance remains separate.

PASS.

G6 — AI model evaluation

Subject: model/version.

Basis: evaluation profile/thresholds.

Finding: meets/does not meet criteria.

Deployment approval remains separate.

PASS.

G7 — Manufacturing

Subject: product/batch.

Basis: specification.

Inspection/test finding may support release decision, but finding ≠ release.

PASS.

G8 — Professional accreditation

Subject: person/programme.

Basis: accreditation criteria.

Assessment supports accreditation decision; assessor finding ≠ credential itself unless governing process defines it so.

PASS.

Hostile tests

H1 — Self-declared conformance

Allowed as an assertion if provenance identifies self-assessment.

It must not be confused with independent certification.

PASS.

H2 — Assessment produces non-conformance

Assessment model supports negative outcome.

PASS.

H3 — Certification implies legal permission

REJECT. Certification may be relevant evidence/status but does not universally establish legal/runtime permission.

H4 — Accepted exception

Implementation is accepted despite known non-conformance.

Preserve:

  • assessment finding;
  • exception/waiver;
  • acceptance decision.

Do not rewrite finding to conformant.

STRONG PASS.

H5 — Conformant but rejected

Possible due to cost, risk, strategy or other criteria.

PASS — validates conformance ≠ acceptance.

H6 — Version-specific conformance

Subject conforms to profile v1, not v2.

Basis version is mandatory where material.

PASS.

H7 — Two assessors disagree

Preserve two Assessment Assertions with provenance and conflict.

No universal winner.

PASS.

H8 — Runtime drift

Prior conformance remains historical; changed observed state may trigger reassessment.

Do not silently erase prior finding.

PASS.

H9 — Partial conformance

Possible only if basis/domain semantics permit meaningful partiality.

Do not assume universal partial-conformance semantics.

PASS WITH OUTCOME-GOVERNANCE GUARDRAIL.

H10 — Automated validator

Machine can produce assessment assertion if method/provenance is explicit.

Human assessor not mandatory.

PASS.

H11 — Conformance inferred from implementation

REJECT. IMPLEMENTED role alone cannot establish conformance.

H12 — Conformance inferred from observed success

REJECT. Successful runtime outcome may be evidence but does not prove all requirements.

Relationship to RRAP

RRAP can describe roles of artefacts/evidence:

  • requirement/profile as REFERENCE;
  • control design as DESIGNED;
  • configured control as IMPLEMENTED;
  • test evidence as OBSERVED.

Assessment Assertion then evaluates a subject/aspect against the explicit basis.

RRAP does not itself assess conformance.

Relationship to QMAP

QMAP can map requirements across frameworks/customer controls.

A mapping from requirement→control does not establish conformance.

Assessment Assertion may reference QMAP mappings as evidence/context, but remains independent.

Relationship to Commons Non-Promotion Rule

Direct applications:

  • IMPLEMENTED ≠ CONFORMANT.
  • OBSERVED SUCCESS ≠ CONFORMANT.
  • CONFORMANT ≠ ACCEPTED.
  • ACCEPTED ≠ AUTHORISED.
  • CERTIFIED ≠ RUNTIME ADMISSIBLE.

Every transition needs its own licensed basis.

Prior-art posture

Assessment/conformance models are established across SHACL, testing, certification, audit, assurance and compliance domains.

Do not claim invention.

Potential Commons contribution is a cross-domain assertion profile preserving assessment basis, scope, provenance and downstream standing separation.

Naming candidates

Conformance Profile

REJECT — too broad and outcome-biased.

Assessment Assertion Profile — AAP

STRONG SEMANTIC FIT, but acronym is generic/overloaded.

Qualified Assessment Assertion Profile — QAAP

Signals context/provenance but “qualified” may imply quality.

Assessment Finding Profile — AFP

Readable, but “finding” can imply human/audit process and understate machine validation.

Preferred working concept: Assessment Assertion Profile.

Do not formalise name yet.

Decomposition finding

Do not build one Commons profile containing:

  • assessment;
  • conformance;
  • acceptance;
  • authority;
  • admissibility.

Instead:

Assessment Assertion may support separately governed downstream decisions/statuses.

This is consistent with RRAP/QMAP architecture.

Experiment result

8/8 generality cases PASS.

12/12 hostile cases survive with guardrails.

Decision

CC-EXP-C05-CONF-01 — DECOMPOSITION / GENERALITY PASS.

  1. Reject monolithic Conformance/Acceptance profile.
  2. Advance Assessment Assertion Profile as candidate semantic core.
  3. Keep acceptance/authority/admissibility external.
  4. Reuse domain-specific outcome vocabularies where possible.
  5. Do not admit/publish yet.

Next

Run prior-art/reduction against:

  • SHACL validation reports/results;
  • test/assurance/audit assertion patterns;
  • PROV-O;
  • credential/certification models where relevant;
  • evidence vocabularies.

Goal: determine whether Commons needs an Assessment Assertion Profile or only guidance over existing standards.

Linked

🔎CC-EXP-C05-CONF-02 — Assessment Assertion Prior-Art & Standards Reduction v0.1