📐

CC-RSRP-SPEC-01 — Representation Standing Role Profile — Candidate Specification v0.1

Specification ID: CC-RSRP-SPEC-01

Version: 0.1 Candidate

Date: 19 September 2026

Standing: INTERNAL — CANDIDATE SPECIFICATION FOR HOSTILE REVIEW. NOT ADMITTED. NOT PUBLIC. NOT MACHINE-READABLE.

Purpose

The Representation Standing Role Profile (RSRP) is a small cross-domain semantic pattern for declaring the role under which a representation/evidence item is relied upon relative to a specific subject and proposition/aspect.

It prevents implicit promotion among:

REFERENCE · DESIGNED · IMPLEMENTED · OBSERVED.

Scope

RSRP defines four role identifiers, contextual role-assignment semantics, minimum qualifiers, anti-collapse invariants and interoperability guidance.

It does not define truth, authority, institutional acceptance, provenance, observation, epistemic state, conformance, workflow/lifecycle, digital twins, architecture language or execution admissibility.

Standing Role Assignment

A Standing Role Assignment states that a representation/evidence entity is being treated in a declared role relative to a declared subject and proposition/aspect, within applicable scope/context/time and provenance.

Roles are contextual, non-exclusive and may conflict or be superseded.

Roles

REFERENCE

A representation used as source, baseline, comparison, standard or pattern.

Does not imply accepted design, implementation, conformance, observation or non-authoritativeness.

DESIGNED

A representation expressing intended arrangement, behaviour, structure, requirement or target state.

Does not imply institutional acceptance, implementation, conformance or runtime behaviour.

IMPLEMENTED

Evidence/representation supporting that a declared subject/aspect has been realised, configured, deployed, constructed or instantiated.

Does not imply conformance, current operation, correct behaviour, observation or fitness.

OBSERVED

Evidence supporting a bounded proposition about what was detected, measured, recorded or otherwise evidenced under declared observation context/time.

Does not imply objective truth, accepted interpretation, direct observation where inference is involved, current state outside the interval or conformance.

Mandatory qualifiers

Every material assignment identifies:

  1. role
  2. subject
  3. proposition/aspect
  4. provenance/evidence reference

When material also identify:

  1. purpose
  2. context/boundary
  3. effective/observation time.

Linked but separate concerns

RSRP may reference but does not define:

  • acceptance/standing authority;
  • epistemic mode;
  • conformance;
  • conflict/disagreement;
  • confidence/qualification;
  • supersession;
  • external authority.

Core invariants

  1. Role is contextual, not intrinsic.
  2. Roles are non-exclusive.
  3. Role ≠ epistemic mode.
  4. Role ≠ acceptance/authority.
  5. Role ≠ conformance.
  6. Role ≠ truth.
  7. Roles are not a mandatory lifecycle.
  8. REFERENCE ≠ DESIGNED.
  9. DESIGNED ≠ IMPLEMENTED.
  10. IMPLEMENTED ≠ OBSERVED.
  11. OBSERVED ≠ accepted interpretation.
  12. OBSERVED ≠ current outside temporal scope.
  13. REFERENCE does not mean non-authoritative.
  14. IMPLEMENTED is subject/aspect/environment relative.
  15. Conflicting assignments/evidence may coexist.
  16. Later assignments do not erase history.
  17. Conformance identifies its target/constraint separately.
  18. Availability/boundary crossing does not promote role/standing.

Interoperability

PROV-O: reuse provenance, derivation, revision, attribution, generation/use and qualified provenance.

SOSA/SSN: reuse observation/result/feature/property/procedure/time semantics where applicable. RSRP OBSERVED is a standing role, not a replacement Observation class.

SHACL: reuse validation/conformance semantics where required. IMPLEMENTED/OBSERVED do not imply conformance.

Domain vocabularies: reuse BIM/IFC, software, digital-twin, regulatory, architecture and sector semantics. RSRP overlays standing role only.

Examples

Software: protocol reference → accepted design → deployed implementation → runtime trace.

Building: code/reference → approved design → as-built evidence → inspection/sensor evidence.

Health: population guideline → patient care plan → administered treatment → patient outcome measurement.

Cybersecurity: framework → target control design → configured control → runtime/log/test evidence.

Digital twin: twin may be DESIGNED/IMPLEMENTED relative to itself; predicted physical state is not directly OBSERVED physical state without evidence.

Regulation: regulation may have REFERENCE role in a mapping while independently carrying legal authority.

Conflict: configuration evidence supports IMPLEMENTED(active); runtime evidence supports OBSERVED(inactive). Preserve both and the conflict.

AI design: generated proposal does not gain accepted DESIGNED standing merely because it contains design content.

Adoption

A consumer adopts RSRP when it uses role meanings consistently, binds assignments to subject + proposition/aspect, preserves provenance, avoids prohibited promotions, preserves relevant time/context and does not claim RSRP establishes truth, authority or conformance.

Candidate conformance

A future implementation could claim profile conformance only if:

  • required qualifiers are representable;
  • roles are contextual/non-exclusive;
  • historical/conflicting assignments can be preserved;
  • role/epistemic/authority/conformance remain separable;
  • provenance is reconstructable;
  • role semantics are not weakened.

No Commons conformance programme currently exists.

Hostile specification review

  • DESIGNED implies accepted? NO — PASS.
  • OBSERVED can hide inference? NO; epistemic mode separate — PASS.
  • One entity multiple roles? YES — PASS.
  • Role can independently be authoritative? YES — PASS.
  • IMPLEMENTED implies conformance? NO — PASS.
  • Conflicting observations? PRESERVE — PASS.
  • Sequential lifecycle required? NO — PASS.
  • Competes with PROV/SOSA/SHACL? NO — PASS.
  • Boundary crossing promotes standing? NO — PASS.
  • Arqua dependency required? NO — PASS.

Hostile specification result: PASS.

Remaining risks

  1. focused generic role-vocabulary prior-art still required;
  2. “standing” may be confused with legal/institutional standing;
  3. design-content vs accepted DESIGNED role needs clear communication;
  4. OBSERVED may be mistaken for direct sensory observation;
  5. formal representation undecided;
  6. IP/publication review incomplete.

Naming

Preferred internal name remains:

Representation Standing Role Profile (RSRP).

Alternatives to test:

  • Representation Role Profile;
  • Representation Reliance Role Profile;
  • Evidence & Representation Role Profile.

Admission checklist

Cross-domain generality
Initial PROV-O / SOSA-SSN review
Hard counterexamples
Broader standards reduction
Candidate specification
Hostile specification review
Focused generic-role prior-art
Naming review
IP/publication review
Commons governance admission decision
Public namespace/version decision
Machine-readable implementation decision

Decision

CC-RSRP-SPEC-01 v0.1 CANDIDATE — SPECIFICATION HOSTILE REVIEW PASS.

RSRP is coherent enough for an admission decision package, but admission remains blocked by prior-art, naming, IP/publication and governance review.

No publication, namespace, schema or implementation is authorised.

Linked