Experiment ID: CC-EXP-C03-01

Version: 0.1

Date: 19 September 2026

Candidate: CC-C03 — Reference / Designed / Implemented / Observed

Standing: INTERNAL — EXECUTED COMMONS ADMISSION EXPERIMENT. NO COMMONS ADMISSION OR PUBLICATION AUTHORISED.

Research question

Is the distinction:

Reference ≠ Designed ≠ Implemented ≠ Observed

general, semantically stable and useful outside the Arqua/framework cases that originally exposed it?

Candidate definitions

Reference

An externally or internally defined model, pattern, standard, baseline or comparison object used to inform, classify or evaluate another object.

A Reference does not automatically have standing as the target institution's accepted design.

Designed

A representation of an intended or accepted future/current arrangement, behaviour, structure or state.

Designed does not prove implementation or observed reality.

Implemented

A realised/configured/deployed arrangement intended to instantiate all or part of a design/reference.

Implemented does not prove actual runtime behaviour or fitness.

Observed

Evidence-bearing manifestation of what occurred or existed under a declared observation boundary/time/context.

Observed does not automatically become accepted design or authoritative interpretation.

Hypothesis

The four roles are distinct across materially unrelated domains and can be connected through typed relations without imposing a universal lifecycle.

Experiment set

E1 — Building / construction

Reference: building code / standard detail / reference pattern.

Designed: approved architectural/engineering design.

Implemented: constructed building/system.

Observed: inspection/sensor/as-built evidence.

Challenge: an as-built drawing may itself be a representation, not direct reality.

Result: PASS. The roles remain distinct; “observed” requires evidence/provenance rather than assuming an as-built claim is observation.

E2 — Clinical / health research

Reference: clinical guideline or population evidence.

Designed: patient-specific care plan/intervention intent.

Implemented: treatment actually administered.

Observed: patient measurements/outcomes.

Challenge: do not infer individual state directly from population reference.

Result: STRONG PASS. This reproduces the representation-sufficiency boundary that helped trigger the wider work.

E3 — Manufacturing

Reference: industry/product standard.

Designed: product/process specification.

Implemented: manufactured configuration/process.

Observed: inspection/telemetry/quality evidence.

Result: PASS.

E4 — Software

Reference: protocol/standard/reference architecture.

Designed: solution architecture/API design.

Implemented: deployed code/configuration.

Observed: runtime traces/behaviour.

Challenge: source code may be implementation artefact but does not prove deployed/runtime state.

Result: STRONG PASS.

E5 — Public policy / regulation

Reference: policy framework/guidance/comparative model.

Designed: enacted/approved programme or operating design.

Implemented: actual administrative mechanisms/processes.

Observed: measured delivery/outcomes.

Challenge: legislation/authority cannot be reduced to “reference”.

Result: PASS WITH AUTHORITY GUARDRAIL. The pattern must not classify an authoritative legal instrument merely as non-authoritative reference where it is actually applicable authority.

E6 — Financial reporting/control

Reference: accounting/control framework.

Designed: institution's accepted accounting/control policy and control design.

Implemented: configured processes/systems/controls.

Observed: transactions, control evidence, audit observations.

Result: PASS.

E7 — Cybersecurity

Reference: security framework/baseline.

Designed: target security architecture/control design.

Implemented: configured controls.

Observed: logs, scans, incidents, test evidence.

Challenge: scanner result may be an observation claim requiring qualification.

Result: PASS WITH EVIDENCE-STANDING GUARDRAIL.

E8 — Machine learning

Reference: benchmark/model card/reference model/requirement.

Designed: intended model/system architecture and evaluation plan.

Implemented: deployed model/configuration/pipeline.

Observed: actual inputs/outputs/performance/drift evidence.

Result: PASS.

E9 — Legal contract execution

Reference: template/model clause.

Designed: negotiated agreement draft/intended arrangement.

Implemented: executed contractual arrangement and operational controls.

Observed: performance/events/evidence.

Challenge: an executed contract itself carries legal standing, so “implemented” must not erase legal-document standing.

Result: PASS WITH MULTI-STANDING GUARDRAIL.

E10 — Natural environment

Reference: ecological/climate model/reference condition.

Designed: restoration/intervention plan.

Implemented: physical intervention.

Observed: measured ecosystem state.

Result: PASS.

Counterexample tests

CEX-01 — No design exists

A naturally occurring phenomenon may have Reference and Observed objects with no Designed/Implemented stages.

Result: PASS if the pattern is roles, not mandatory sequence.

CEX-02 — Direct implementation from reference

An organisation adopts a standard configuration with little separate design artefact.

Result: PASS. Designed may be implicit/absent; roles do not need one object each.

CEX-03 — One artefact carries multiple roles

An executable infrastructure-as-code file may be both design specification and implementation input.

Result: PASS if roles are contextual/typed and not exclusive classes.

CEX-04 — Observation changes implementation

Adaptive system modifies configuration based on telemetry.

Result: PASS. Observation may trigger governed change; it does not erase role distinctions.

CEX-05 — Simulation

A simulation produces observed simulation results but not observations of production reality.

Result: PASS WITH OBSERVATION-SCOPE requirement.

Key refinement

The candidate should not be modelled as four mutually exclusive ontological classes.

Better:

Reference, Designed, Implemented and Observed are semantic roles/standings that an artefact, representation or evidence item may hold relative to a declared subject, purpose, context and time.

One artefact may carry more than one role for different propositions.

Proposed core relations

Candidate neutral relations:

• INFORMED_BY_REFERENCE
• DESIGNED_AS
• IMPLEMENTED_AS
• OBSERVED_AS
• CONFORMS_TO
• DEVIATES_FROM
• EVIDENCES
• SUPERSEDES

These require prior-art/vocabulary review before minting Commons predicates.

Required qualifiers

Minimum:

• subject;
• role;
• proposition/scope;
• source;
• effective/observation time;
• evidence/provenance;
• standing/acceptance where applicable.

Optional:

• mapping purpose;
• confidence/qualification;
• supersession;
• conflict.

Anti-collapse rules

1. Reference ≠ designed customer/institutional standing.
2. Designed ≠ implemented.
3. Implemented ≠ observed behaviour.
4. Observed ≠ accepted interpretation.
5. Observation claim ≠ reality without evidence boundary/provenance.
6. Reference may itself be authoritative for some propositions; “reference” does not mean “non-authoritative”.
7. Roles need not occur sequentially or all be present.
8. One artefact may hold multiple roles relative to different propositions.
9. Conformance to reference/design does not prove runtime fitness.
10. Observed deviation does not automatically rewrite accepted design.

Generality result

10/10 domain fixtures survived, with guardrails required for:

• applicable legal/authority standing;
• evidence qualification;
• multi-role artefacts;
• observation scope.

No domain required collapsing the four roles.

Semantic stability result

PASS WITH REFINEMENT.

The original sequence-like formulation:

Reference → Designed → Implemented → Observed

should be replaced in Commons research by a four-role model, because:

• stages can be absent;
• order can vary;
• one artefact can occupy several roles;
• observed evidence can precede design;
• adaptive systems can cycle repeatedly.

Commons admission result

ADVANCE TO ADMISSION STAGE 2 — PRIOR-ART / EXISTING VOCABULARY REVIEW.

Do not admit/publish yet.

Before admission:

1. compare with W3C PROV-O;
2. compare with digital twin/model–instance vocabularies;
3. compare with configuration/as-built/as-operated patterns;
4. compare with software specification/implementation/runtime terminology;
5. compare with evidence/observation vocabularies such as SOSA/SSN where relevant;
6. determine whether Commons needs new terms or only a reusable profile/pattern over existing vocabularies;
7. IP/publication review.

Candidate Commons artefact name

Working title:

Codex Commons — Representation Standing Roles (RSR)

Candidate roles:

REFERENCE · DESIGNED · IMPLEMENTED · OBSERVED

Alternative title:

Reference–Design–Implementation–Observation (RDIO) Pattern

Do not name publicly until prior-art review.

Decision

CC-EXP-C03-01 — EXPERIMENT PASS.

CC-C03 is sufficiently general and stable to progress from extraction to prior-art/vocabulary review.

It is not admitted to Codex Commons by this experiment.

Linked

• 🧬CC-EXTRACT-ARQUA-01 — Commons Candidate Extraction from Recent Arqua–CR Work v0.1
• Codex Commons