Conformance and Evidence Framework
Documenting framework conformance, evaluation readiness, implementation evidence, and evidence maturity without treating them as interchangeable.
A scoped framework for assessing whether a defined system or implementation satisfies documented Robbie’s Razor requirements—and for recording what has been implemented, tested, supported, challenged, or left unknown.
Compliance boundary: A conformance finding does not automatically establish efficiency, effectiveness, safety, environmental benefit, certification, licensing status, or formally validated performance.
Keep These Distinct
Canonical and Assessment Notice
This framework is governed by GC-MRD-v2.0 and should be read with the Grand Compression Canonical Claims Register, the Razor Auditor, and the Razor Evaluation Protocol.
“When competing explanations exist, prefer the model that follows compression → expression → memory → recursion.”
Canonical formulation of Robbie’s Razor. This sentence should not be paraphrased when presented as the canonical law.
| Determination | What it establishes |
|---|---|
| Framework conformance | Whether the assessed unit satisfies identified and versioned Robbie’s Razor framework requirements. |
| Evaluation readiness | Whether the system boundary, workload, baseline, quality gate, instrumentation, and evidence procedures are sufficient to run a valid test. |
| Implementation maturity | Which documented components exist, operate, are versioned, and can be observed or inspected. |
| Evidence maturity | What preregistered testing, result records, adverse findings, replication, and independent review are available. |
| Validated performance | Whether a defined performance claim has satisfied the applicable evidence-state process under a registered scope. This is not created automatically by the other four determinations. |
Building a controller, memory layer, tool, benchmark, registry, prompt, or repository asset can demonstrate implementation. It does not independently establish effectiveness.
Licensing, payment, integration, commercial use, or institutional participation demonstrates access or adoption—not technical validation or certification.
A documented observation or conformance record is not automatically a Supported claim. Formal evidence states require their own review process.
The previous R0–R5 ladder, 0–20 score, mappings such as “18–20 → R5,” and statements such as “certified at R3.7” are not carried forward as controlling certification language on this rebuilt page.
No R-level should be assigned, scored, or described as certification unless its definition, requirements, decision authority, versioning rules, and evidentiary meaning are explicitly confirmed in GC-MRD-v2.0. Any retained historical reference must be labeled non-controlling.
The compliance framework therefore records narrow, attributable determinations about a defined assessment unit. It does not classify an entire company, model family, architecture, or industry as universally Razor-compliant.
Controlling rule: When historical page language conflicts with GC-MRD-v2.0, the current Master Reference Document and Canonical Claims Register govern.
Foundational Definition
Within this framework, Robbie’s Razor compliance means that a specifically defined assessment unit has been examined against an identified, versioned set of applicable Robbie’s Razor requirements and that the resulting conformance findings are supported by attributable evidence.
Compliance = Defined Assessment Unit + Versioned Requirements + Attributable Evidence + Scoped Findings + Dated Decision
Compliance is not an inherent or permanent property of a company, model family, architecture, tool, or implementation. It is a time-bound assessment conclusion tied to what was examined, which requirements applied, what evidence was available, and which limitations or exclusions remained.
The finding identifies the exact framework requirement, authority version, applicability decision, and acceptance condition being assessed.
The conclusion is traceable to documentation, configuration, logs, tests, records, observations, calculations, or other identified evidence.
The finding applies only to the registered system, version, configuration, workload, constraints, period, and evidence boundary.
The decision records its assessment date, evidence period, framework version, and events that require re-evaluation.
Compression, expression, memory, and recursion are assessed as related dimensions rather than isolated labels detached from the complete CEMR sequence.
Nonconformities identify unmet requirements, supporting evidence, consequence, corrective action, responsible owner, and re-evaluation condition.
A compliance statement should identify:
Terminology rule: If no authorized certification process exists, use language such as assessed for conformance, requirement met, requirement not met, or evidence unavailable. Do not issue an unqualified “Razor certified” designation.
Non-Claim Boundary
A conformance finding answers whether a defined assessment unit satisfies identified framework requirements. It does not automatically answer whether the system performs better, costs less, uses fewer resources, produces environmental benefits, or has received formal certification.
A conforming implementation may fail a performance test, and a high-performing implementation may still fail a framework requirement.
| Compliance does not automatically mean | Required boundary |
|---|---|
| Improved performance | Performance claims require a preregistered test, fair baseline, quality gate, defined success threshold, and valid result record. |
| Reduced tokens, FLOPs, latency, or memory | Each resource variable requires its own operational definition, unit, instrumentation, system boundary, and comparative evidence. |
| Lower total cost | Total cost must include material construction, compute, storage, indexing, retrieval, tools, verification, human review, correction, failures, retries, coordination, infrastructure, and maintenance. |
| Improved quality or safety | Correctness, completeness, safety, usefulness, constraint compliance, format compliance, and other quality dimensions require registered acceptance criteria and evidence. |
| Hallucination mitigation | Factual error, unsupported assertion, contradiction, or another failure class must be operationally defined and measured before a scoped finding can be made. |
| Environmental benefit | Energy, cooling, water, carbon, and emissions conclusions require direct telemetry or a defensible accounting model. Token changes alone are insufficient. |
| Formal certification | Certification requires a separate documented scheme, defined decision authority, assessor requirements, surveillance or renewal rules, and an explicit certification decision. |
| Independent validation | Author-created or implementer-created assessments must be distinguished from independent testing, review, and replication. |
| A Supported evidence state | A documented conformance finding does not automatically determine the formal evidentiary status of a technical claim. |
| Licensing status or permission | Conformance, licensing, attribution, commercial permission, and contractual authorization are separate questions. |
| Company-wide or model-wide classification | A finding applies only to the assessed unit. It does not classify an entire company, product family, provider, architecture, or industry. |
Non-claim rule: These events may demonstrate implementation, publication, access, adoption, or commercial activity. They do not independently demonstrate effectiveness or establish formal validation.
Assessment Boundary
Compliance must be assessed against a precisely bounded system or implementation. A company name, model family, architecture label, repository, or general description is not sufficiently specific to receive a defensible compliance finding.
System + Version + Configuration + Workload + Constraints + Measurement Period + Evidence Boundary
The applicable requirement set, assessment date, assessor, and known exclusions are then attached to this unit. A material change to the unit may invalidate the prior finding or require a new assessment.
| Assessment field | Required record | Boundary purpose |
|---|---|---|
| System | Model, application, controller, memory layer, retrieval system, tools, human operations, infrastructure, and included dependencies. | Identifies what is actually being assessed. |
| Version | Model release, software build, prompt version, controller version, memory schema, dataset version, and dependencies. | Prevents findings from drifting across silent updates. |
| Configuration | System instructions, decoding, routing, retrieval, state rules, tools, permissions, limits, retries, batching, and hardware allocation. | Defines how the assessed system operates. |
| Workload | Task set, data source, user population, sampling method, difficulty, dependencies, accepted outcomes, and exclusions. | Limits conclusions to the assessed use case. |
| Constraints | Quality, safety, privacy, time, context, compute, storage, cost, tool, format, legal, and stopping constraints. | Defines the requirements under which conformance must hold. |
| Measurement period | Assessment start and end, evidence dates, operating conditions, trial dates, and known changes during the period. | Makes the finding time-bound. |
| Evidence boundary | Documents, configurations, logs, tests, telemetry, interviews, calculations, unavailable records, and known evidence gaps. | Prevents findings from extending beyond what was inspected. |
| Applicable requirements | Requirement identifiers, GC-MRD version, applicability decisions, acceptance criteria, exclusions, and not-applicable justifications. | Defines what compliance means for this unit. |
| Assessment authority | Assessor, organization, relationship to the system, conflicts of interest, review role, and decision authority. | Distinguishes self-assessment, second-party review, independent review, and any authorized certification decision. |
A named model version using a versioned CEMR instruction on a registered analysis workload under fixed decoding, context, quality, and evidence conditions.
A versioned controller, model, tool set, memory schema, and stop policy assessed on a registered agent workload during a stated operating period.
A defined AI-and-human workflow with registered handoffs, review responsibilities, tools, decision rights, quality rules, and complete evidence boundaries.
Scope-change rule: A material change to the model, version, configuration, workload, constraints, evidence boundary, applicable requirements, or operating environment may require the prior finding to be qualified, suspended, expired, or replaced by a new assessment.
Controlling-Status Notice
Earlier versions of this page presented R0–R5 as a graduated compliance ladder and mapped a 0–20 CEMR score to those levels. The same page also included example language such as “certified at R3.7.”
The previous R0–R5 ladder and 0–20 score are not controlling certification instruments under this rebuilt GC-MRD-v2.0 page.
No R-level should be assigned unless the current governing authority explicitly defines the level, its requirements, assessment procedure, evidence threshold, decision authority, versioning rules, expiration conditions, and relationship to formal certification. Without those elements, an R-level would be an unsupported label rather than a defensible compliance decision.
| Previous element | Current treatment | Reason |
|---|---|---|
| R0–R5 level names | Historical and non-controlling unless explicitly confirmed in GC-MRD-v2.0. | A level system requires canonical definitions, applicable requirements, evidence rules, and decision authority. |
| 0–20 CEMR score | Not used as the controlling compliance decision. | Equal phase weighting and score thresholds were not shown to be validated across systems, workloads, or domains. |
| Score-to-level mapping | Removed from current controlling language. | A total score can conceal a material failure in quality, provenance, memory, safety, or another required dimension. |
| “Certified at R3.7” | Do not use as a certification statement. | No decimal-level certification procedure, authorized decision, or surveillance process was established on the previous page. |
| “Razor-aligned architecture” | May be used only as a scoped descriptive or Proposed statement with defined features. | Architectural resemblance does not establish framework conformance or validated performance. |
| Expected level outcomes | Treat as Proposed until separately tested. | Claims of token savings, stability, bounded recursion, or maximum efficiency require empirical evidence. |
The rebuilt framework uses requirement-by-requirement findings so that a material failure cannot be hidden inside an aggregate score. Each requirement should preserve:
Future-level rule: If GC-MRD-v2.0 or a later governing version formally establishes maturity or conformance levels, those levels should be adopted only with their exact canonical definitions. Organization-created maturity scales must be labeled local and must not be represented as canonical R-level certification.
Requirement Register
A compliance assessment begins by identifying which GC-MRD-v2.0 and Robbie’s Razor requirements apply to the registered assessment unit. Requirements should not be inferred from historical page language, reconstructed from obsolete scores, or invented during the assessment.
Authority boundary: Only requirements traceable to the governing framework should be presented as canonical Robbie’s Razor requirements. Organization-specific controls may be added, but they must be clearly identified as local rather than canonical.
| Field | Required record |
|---|---|
| Requirement ID | A stable identifier that can be cited in findings, corrective actions, result records, and re-evaluations. |
| Authority and version | GC-MRD version, canonical claim, framework page, section, and applicable modification date. |
| Requirement text | The exact controlling requirement without interpretive expansion or silent paraphrase. |
| Requirement intent | The function, risk, or framework relationship the requirement is intended to preserve. |
| Applicability decision | Why the requirement applies, does not apply, or cannot yet be determined for the assessed unit. |
| Acceptance criteria | The observable conditions and thresholds required to determine whether the requirement is satisfied. |
| Required evidence | Documents, configurations, logs, tests, telemetry, interviews, calculations, or other evidence needed for a defensible finding. |
| Assessment method | Inspection, observation, testing, recalculation, reproduction, interview, sampling, or another registered method. |
| Finding | Whether the requirement was satisfied, not satisfied, not applicable, or could not be determined from available evidence. |
| Supporting statements | Atomic statements labeled Documented, Calculated, Inferred, Proposed, or Unknown. |
| Nonconformity and action | Evidence of the gap, consequence, corrective action, owner, due date, verification method, and closure status. |
| Review metadata | Assessor, review date, conflicts, evidence period, limitations, approval role, and re-evaluation trigger. |
The applicable set will depend on the assessed unit, but a complete review should consider whether requirements exist in these families:
Correct framework name, canonical law, attribution, authority version, and claim-register relationship.
System, version, configuration, workload, constraints, period, dependencies, and evidence boundary.
Documented compression, expression, memory, and recursion requirements, interfaces, state, constraints, and observable behavior.
Acceptance criteria, equivalent standards, verification, correction, failure treatment, and quality-first interpretation.
Evidence identity, source, version, collection method, custody, transformation, limitation, and reviewer access.
Complete cost boundary, units, allocations, missing categories, intervention overhead, and cost per accepted outcome.
Failure conditions, nonconformity records, corrective action, verification, recurrence prevention, and re-evaluation.
Domain-transfer restrictions, environmental boundaries, finding labels, evidence states, and public claim controls.
Applicability rule: A requirement may be excluded only through a documented applicability decision. Convenience, missing implementation, or unavailable evidence does not make a requirement inapplicable.
Acceptance Before Efficiency
A system cannot establish improved efficiency merely by producing a shorter, faster, or less expensive result. Any performance or efficiency conclusion must first show that the baseline and intervention were judged against the same preregistered acceptance standard.
A resource reduction is not an efficiency improvement if the result fails the same quality gate or shifts material work into verification, correction, retries, or human review.
| Requirement | Required evidence |
|---|---|
| Registered quality dimensions | Applicable correctness, completeness, safety, usefulness, constraint, format, verification, correction, and memory-fidelity definitions. |
| Acceptance threshold | The minimum score or complete set of conditions required for an accepted outcome. |
| Equivalent standard | Evidence that the baseline and intervention were evaluated using the same acceptance criteria, rubric, validation method, and correction policy. |
| Evaluation method | Exact match, executable tests, schema validation, source checking, expert review, user acceptance, or another registered method. |
| Evaluator and adjudication | Evaluator identity or system, rubric version, blinding, disagreement procedure, calibration, and final adjudication rule. |
| Outcome accounting | Accepted, failed, corrected, excluded, timed-out, invalid, and unscorable trials preserved according to registered rules. |
| Verification burden | Automated checks, model calls, tool calls, reviewer time, latency, and financial cost required to determine acceptance. |
| Correction burden | Retries, edits, state repair, re-execution, tool recovery, human intervention, and re-verification required to reach acceptance. |
| Acceptance-rate reporting | Acceptance rate for each arm, counts by outcome class, uncertainty, subgroup results, and reasons for exclusions. |
| Efficiency interpretation | Resource results reported per attempted task and per accepted outcome, with total-cost categories and quality regressions visible. |
Establishes whether the quality gate is documented, versioned, equivalent across arms, operationally defined, and supported by required records.
Establishes what happened when the registered system was tested. This requires empirical results and cannot be inferred from process conformance alone.
Quality-gate rule: Whenever the assessment supports a technical performance or efficiency claim, the quality gate is mandatory. If quality evidence is unavailable or the intervention fails the threshold, the corresponding efficiency conclusion is not established.
Traceable Assessment Evidence
Every requirement-level conclusion must be traceable to identifiable evidence. The assessor should be able to determine where the evidence came from, which system and version it describes, how it was collected, whether it was transformed, and which limitations affect its use.
Evidence boundary: A claim, diagram, policy, configuration, or implementation description is not sufficient merely because it exists. The assessment must establish its identity, version, applicability, provenance, and relationship to the system actually examined.
| Evidence field | Required record |
|---|---|
| Evidence ID | Stable identifier linking the evidence to requirements, findings, corrective actions, and review decisions. |
| Evidence type | Document, configuration, source code, schema, log, test, telemetry record, interview, calculation, execution artifact, or other identified form. |
| Source and owner | Originating person, system, organization, repository, service, instrument, or operational process. |
| System linkage | The system, version, configuration, workload, component, and assessment period to which the evidence applies. |
| Creation and collection | Creation date, collection date, method, instrument, sampling rate, collection authority, and operating conditions. |
| Version and integrity | Version, revision history, checksum or other integrity control, custody, access history, and supersession status where applicable. |
| Transformations | Filtering, aggregation, redaction, calculation, normalization, conversion, exclusion, or other processing applied to the source evidence. |
| Units and definitions | Metric definition, physical or operational unit, tokenizer, measurement point, formula, allocation rule, and missing-value code. |
| Access and confidentiality | Who may inspect the evidence, applicable restrictions, redaction, retention, deletion, encryption, and reviewer-access boundaries. |
| Limitations | Missing fields, uncertainty, sampling limitations, conflicts, stale records, unobserved variables, inaccessible source material, and alternative explanations. |
Architecture records, schemas, specifications, policies, requirement mappings, configuration manifests, and change records.
Source code, prompts, controllers, state schemas, retrieval rules, tool permissions, tests, deployment records, and operating procedures.
Inputs, outputs, tool calls, stored state, retrieval events, execution results, failures, retries, telemetry, and accepted outcomes.
Preregistrations, baseline records, quality decisions, result records, calculations, deviations, replications, and reviewer findings.
Reasoning-privacy rule: A compliance assessment does not require private chain-of-thought. It should use authorized and observable inputs, outputs, tool calls, stored state, retrieval behavior, execution results, telemetry, quality decisions, and other attributable evidence.
Missing-evidence rule: When evidence required for a conclusion is unavailable, inaccessible, stale, inconsistent, or outside the assessment boundary, the affected statement should be labeled Unknown. Missing evidence must not be converted into an assumption of conformance.
Compression → Expression → Memory → Recursion
CEMR conformance examines whether the assessed system has documented, versioned, observable, and testable requirements for compression, expression, memory, and recursion—and whether the interfaces between those dimensions preserve the state needed by the complete process.
Conformance boundary: The presence of a compressor, concise output, cache, database, vector store, controller, or loop does not automatically establish CEMR conformance. The assessment must examine the applicable requirement, function, state, constraints, provenance, interface, and evidence.
| Dimension | Conformance questions | Possible evidence | Material risks |
|---|---|---|---|
| Compression | Is the representation boundary defined? Are required identity, relationships, provenance, constraints, version state, and retrieval pathways identified and preserved? | Schemas, source-to-state mappings, compression rules, fidelity tests, constraint fixtures, redundancy records, and reconstruction logs. | Truncation, detached provenance, lost constraints, ambiguous identity, stale state, and shifted reconstruction burden. |
| Expression | Is the required output or action defined? Does expression preserve required meaning, comply with constraints, and support the registered quality gate? | Output schemas, format rules, tool policies, acceptance tests, execution records, source checks, and correction histories. | Missing required elements, unsupported additions, constraint violations, failed execution, and excessive verification or correction. |
| Memory | Does reusable state preserve identity, relationships, provenance, constraints, version state, and retrieval pathways? Is reuse appropriate and access controlled? | State schemas, write and retrieval logs, version records, collision tests, retention rules, access controls, deletion tests, and reuse records. | State collision, contamination, stale retrieval, lost provenance, unauthorized reuse, constraint decay, and unavailable deletion. |
| Recursion | Are recursive steps, state transitions, depth, refresh behavior, branch policy, stopping rules, escalation, and recovery procedures documented and observable? | Controller rules, state-transition logs, depth records, refresh schedules, stop tests, error propagation fixtures, recovery records, and resource budgets. | Unbounded loops, premature stopping, repeated rework, error amplification, constraint loss, unnecessary refresh, and hidden resource escalation. |
A complete conformance assessment should examine not only the four dimensions but also the transitions between them:
Can the compressed state support the required output or action without unacceptable reconstruction or information loss?
Are validated outcomes stored with the correct identity, provenance, constraints, version state, and permissions?
Can the appropriate state be retrieved and reused in a later operation without contamination, stale versioning, or constraint loss?
Are updates, corrections, branches, stop decisions, and new state versioned and returned to the cycle with preserved provenance?
CEMR rule: CEMR conformance establishes whether applicable framework requirements are present and supported by evidence. It does not establish that the implementation improves efficiency or performance; those claims require the Razor Evaluation Protocol.
Whole-System Cost Boundary
A system making an efficiency or cost claim must define and document the complete material cost boundary. Compliance with total-cost requirements means that the accounting method, categories, units, allocations, omissions, and normalization rules are present and traceable.
Single-metric boundary: Fewer output tokens, model calls, steps, or milliseconds cannot establish system-level efficiency if material work has shifted into context construction, retrieval, tools, storage, verification, correction, human review, retries, coordination, or maintenance.
| Cost category | Required boundary record |
|---|---|
| Input and context construction | Prompt preparation, context assembly, document processing, data transformation, state serialization, and intervention instructions. |
| Model and compute calls | Primary generations, auxiliary models, embeddings, rerankers, evaluators, controllers, routing, and recovery calls. |
| Storage | Transcripts, state, caches, registries, logs, artifacts, backups, retention periods, and storage operations. |
| Indexing | Parsing, chunking, embedding, metadata, graph construction, updates, refresh, and re-indexing. |
| Retrieval | Queries, search, filtering, reranking, graph traversal, data transfer, retrieval failures, and retries. |
| Tool execution | API calls, code execution, browsing, database operations, external services, side effects, and resulting data transfer. |
| Verification | Automated tests, source checks, schema validation, comparison models, expert review, and user acceptance. |
| Human review | Evaluation, annotation, adjudication, oversight, escalation, approval, and exception handling. |
| Correction | Editing, re-prompting, state repair, tool recovery, source replacement, re-execution, and re-verification. |
| Failed runs and retries | Timeouts, invalid outputs, tool failures, rejected outcomes, restarts, abandoned runs, and recovery attempts. |
| Coordination | Multi-agent handoffs, orchestration, scheduling, synchronization, conflict resolution, and result merging. |
| Infrastructure | Compute, networking, databases, observability, security, orchestration, idle allocation, and shared services. |
| Maintenance | Monitoring, updates, prompt maintenance, index refresh, registry repair, evaluation upkeep, and operational support. |
Total-cost conformance establishes that the cost boundary, categories, units, evidence, allocations, and missing values are documented according to applicable requirements.
Total-cost performance establishes what happened in a valid comparative evaluation. It cannot be inferred from accounting-process conformance alone.
Total-cost rule: Do not issue an unqualified efficiency finding when material costs are missing. If an unavailable category could change the conclusion, the system-level efficiency result should remain Unknown or be limited to the directly measured component.
Evidence That a Requirement Was Implemented
Implementation evidence shows whether a documented framework component, control, interface, or operating procedure exists and corresponds to the assessed system version. It can support a conformance finding about what was built or deployed.
Implementation boundary: Evidence that a prompt, controller, memory layer, registry, retrieval system, tool policy, test suite, or other component exists does not establish that it improves quality, efficiency, stability, safety, or environmental performance.
| Evidence family | Possible evidence | What it may establish |
|---|---|---|
| Design evidence | Architecture diagrams, requirement mappings, interface specifications, data models, state schemas, threat models, and design decisions. | The intended component, boundary, inputs, outputs, controls, and relationships are documented. |
| Build evidence | Source code, prompts, controller rules, configuration, schemas, migrations, build artifacts, dependency manifests, and tests. | The specified component exists in an identifiable implementation version. |
| Deployment evidence | Release records, deployment manifests, environment configuration, endpoint records, approvals, and rollback procedures. | The component was deployed to a named environment under a defined configuration. |
| Operational evidence | Execution logs, state transitions, retrieval events, tool calls, access records, monitoring, failures, alerts, and incident records. | The component operated during the stated period and produced observable events. |
| Control evidence | Permissions, stop rules, escalation paths, version controls, constraint tests, deletion tests, review procedures, and exception handling. | Required boundaries and controls are implemented and can be inspected or tested. |
| Change-management evidence | Version history, review records, approvals, migration plans, compatibility tests, rollback records, and supersession notices. | Changes are attributable, reviewed, and connected to assessment and re-evaluation requirements. |
| Maintenance evidence | Monitoring schedules, index refresh, prompt upkeep, state repair, dependency updates, incident correction, and control verification. | The implementation has defined procedures for continued operation and correction. |
Stable component name, version, owner, repository or source, deployment status, and change history.
Purpose, inputs, outputs, dependencies, permissions, resource limits, and excluded responsibilities.
Which compression, expression, memory, recursion, or cross-phase requirement the component implements.
Quality, safety, privacy, access, version, cost, failure, stopping, escalation, and recovery controls.
Logs, tests, state records, execution outputs, monitoring, configuration snapshots, and other inspectable artifacts.
Unsupported workloads, missing controls, unavailable evidence, known failure modes, and required corrective actions.
Appropriate: “Controller version 2.3 contains a documented stop rule and records observable stop and escalation events for the assessed workload.”
Not established by that evidence: “Controller version 2.3 reduces reasoning cost, prevents unbounded recursion, or improves accuracy.”
Implementation rule: Record only what the implementation evidence establishes. Performance, quality, stability, and efficiency claims require separate evaluation evidence.
Evidence That a Governed Claim Was Validly Tested
Evaluation evidence records what happened when a defined system, authority package, target, baseline, and intervention moved through a registered Robbie’s Razor evaluation. It is required for claims about quality, resource use, cost, memory fidelity, reuse, recursive stability, environmental effects, or other measured performance outcomes.
Under the updated evaluation architecture, empirical evidence begins before a model is called. When the study depends on governed authority, the evaluator must first establish whether the registered sources can define the state against which later preservation, reconstruction, and quality will be judged.
The governing empirical method is the Razor Evaluation Protocol . A compliance assessment may determine whether that method was followed, whether each required gate was respected, and whether the resulting evidence record is complete. It must not rewrite the empirical outcome or substitute a conformance finding for the formal evidence-state process.
Upstream Evidence Requirement
Metrology for Meaning™ establishes the upstream architectural question: which identity, provenance, relationships, versions, rights, and authority rules define the state the evaluation is permitted to call authoritative?
If the study cannot establish that governed state under its frozen Reference Contract, the appropriate evidence is an authority-layer result rather than a fabricated target followed by an invalid model comparison.
Authority Evidence → Reference Gate → Governed Target → Model Evidence → Quality Evidence → Economic Evidence → Result Record
Evidence must show not only what was measured, but whether the study was authorized to reach that measurement.
An upstream gate failure limits the legitimate scope of every downstream claim.
Lock 1
Evidence should show that authority sources, selectors, precedence, normalization, equivalence, binding rules, rights, correction policy, censorship rules, and target construction were fixed before authority discrepancies were observed.
Lock 2
Evidence should show that the prediction, baseline, intervention, Quality Gate, metrics, cost boundary, success threshold, failure rules, sample design, and analysis plan were fixed before comparative results were interpreted.
| Evaluation Element | Required Evidence | Conformance Question |
|---|---|---|
| Governing authority | MRD version, claim identifier, applicable canonical sources, authority hierarchy, supersession rules, protocol version, and governing requirement set. | Was the evaluation tied to the correct and versioned authority? |
| Reference Lock | Frozen authority package, source list, selectors, precedence, required values, relationships, normalization, equivalence, correction policy, rights requirements, binding rules, censorship conditions, and target-construction procedure. | Were the rules for resolving authority fixed before authority was inspected? |
| Authority capture | Capture date and time, source response status, retrieved content, content version or hash where applicable, extracted values, selector results, provenance records, rights values, relationship records, and inaccessible sources. | Can another assessor reconstruct the authority state available to the study? |
| Reference Gate | Availability, unambiguous selection, completeness, cross-source coherence, required binding, rights or authorization status, failed gate where applicable, and final governed-state decision. | Did the authority package validly authorize target construction? |
| Target construction | Target-construction authorization, deterministic or registered procedure, target ID, version or hash where applicable, complete source-to-target provenance, transformations applied, and explicit not-constructed status when the Reference Gate fails. | Was the target constructed only after the required Reference Gate passed? |
| Model-visible input | Exact input-construction procedure, prompts, source visibility, retrieval permissions, hidden-target separation, contamination controls, allowed tools, memory access, and visibility differences between arms. | Did the evaluated conditions receive only the information permitted by the registered design? |
| Evaluation Lock | Time-stamped prediction, baseline, intervention, primary and secondary outcomes, Quality Gate, success threshold, failure conditions, sample design, analysis plan, observation period, missing-data procedure, total-cost treatment, and result-record rules. | Was the downstream decision rule fixed before comparative outcomes were inspected? |
| System boundary | System, version, configuration, workload, constraints, measurement period, evidence boundary, model, tools, memory, retrieval, infrastructure, baseline, intervention, and included human operations. | Was the tested unit complete, stable, attributable, and reproducible? |
| Baseline integrity | Comparator rationale, matched task set, access, tools, prompts, limits, pricing basis, memory state, equivalent configuration, fair tuning, identical acceptance criteria, execution environment, and declared differences. | Was the intervention compared against a defensible matched baseline? |
| Quality Gate | Applicable quality dimensions, threshold, evaluation method, evaluator or judge, adjudication, accepted outcomes, failures, corrections, exclusions, verification burden, correction burden, and unscorable outcomes. | Did each evaluated arm face the same preregistered acceptance standard against the valid target? |
| Metrics and units | Operational definitions, physical or financial units, source, collection procedure, formulas, aggregation, normalization, uncertainty, exclusions, missing values, and declared direction of improvement. | Were the claimed outcomes measured in a reproducible and interpretable form? |
| Sample design | Population, task set, sample size, repetitions, task classes, seeds, allocation, run order, subgroups, stopping rule, independence assumptions, and uncertainty treatment. | Was the sample appropriate for the registered decision? |
| Instrumentation | Equivalent logs, configuration snapshots, trial IDs, timestamps, retrieval events, memory events, state transitions, tool calls, payment events where applicable, resource records, failure records, and instrumentation overhead. | Can the executed evaluation be reconstructed and checked? |
| CEMR results | Compression, expression, memory, recursion, cross-phase, quality, preservation, reuse, failure, and boundary-condition observations actually reached during execution. | Were CEMR outcomes measured rather than inferred from architecture? |
| Economic results | Total costs, avoided recomputation, preservation cost, retrieval cost, verification, maintenance, repair, residual computation, Net Reuse Benefit, break-even, Dynamic Reuse Frontier, Compression Dividend, pricing basis, and explicit not-tested status where the economic layer was not reached. | Was economic interpretation performed only after the required upstream gates permitted it? |
| Physical-resource results | Direct compute telemetry, energy, facility attribution, water, emissions, hardware allocation, uncertainty, boundaries, proxies, and explicit unavailable measurements. | Are physical claims supported by appropriate physical evidence rather than token or monetary proxies alone? |
| Failures and deviations | Authority failures, Quality Gate failures, negative economic results, failed predictions, invalid trials, safety stops, missing data, protocol deviations, exclusions, configuration drift, execution errors, corrections, and censorship events. | Were unfavorable, limiting, and stopped outcomes preserved without reclassification? |
| Result layer | Deepest valid stage reached, authority-layer outcome, model or quality outcome, economic outcome, gate that stopped execution where applicable, target status, model-execution status, economic-analysis status, and all downstream stages not reached. | Does the reported conclusion correspond to what the study actually reached? |
| Result record | Versioned decision, raw-data references, authority records, target status, observations, calculations, result classification, findings, limitations, alternative explanations, stages not reached, authorship, and review status. | Is the bounded conclusion traceable to the registered evaluation? |
| Replication and review | Reproduction, direct replication, independent review, authority re-audit, adverse evidence, changed conditions, conflicts, corrective actions, successor studies, and unresolved questions. | Has the result been examined beyond the original execution and interpretation? |
Layer 1
Establishes what happened during authority capture and the Reference Gate. A failed gate may validly stop the study before target construction.
Layer 2
Establishes what happened after a valid target existed and model, retrieval, or intervention outputs were judged against the registered acceptance standard.
Layer 3
Establishes what happened after reference and applicable quality requirements allowed total-cost or reuse-economic comparison.
Study 008 · Evaluation-Evidence Example
Study 008 captured all required governed leaf values and provenance records, resolved all preregistered selectors, and recorded no source-availability or selector-ambiguity problem.
One required cross-source canonical relationship failed the frozen authority-binding rule. The study therefore produced an authority-layer censored result before hidden-target construction.
Recorded outcome: AUTHORITY_BINDING_CENSORED_BEFORE_TARGET_CONSTRUCTION
Not evaluated: model performance, Quality Gate outcome, cache performance, paid retrieval, x402 payment, reuse economics, or a Study 008 Compression Dividend.
The study did not become invalid merely because it stopped upstream. The frozen rules required the experiment to stop when the required authority relationship could not bind.
The compliance question is therefore whether the study followed the registered decision rule, not whether it reached the model or produced a favorable economic result.
Evaluation Integrity
If the frozen Reference Contract prohibits a transformation, the evaluator must not normalize, reinterpret, substitute, repair, merge, infer, or otherwise modify the authority record merely to allow target construction. If authority repair itself is being studied, it should be defined as a separate intervention with its own preregistered evaluation.
The system boundary, applicable authority, Reference Contract, baseline, Quality Gate, metrics, instrumentation, cost boundary, and decision rules are sufficiently defined to begin the registered process.
The registered authority process produced a valid Reference-Gate decision, including a legitimate censored outcome when target construction was not authorized.
A valid target existed, the permitted baseline and intervention stages executed, and the result record preserves applicable quality, model, resource, failure, and economic outcomes.
A separate formal evidence-state determination made only after the relevant result records, replication, adverse evidence, scope, limitations, and review requirements have been considered.
Evidence Flow
Reference Evidence → Target Status → Model Evidence → Quality Evidence → Economic Evidence → Bounded Result → Replication → Evidence-State Review
Missing-evaluation-evidence rule: If a required stage was not reached, its outcome must not be inferred. Record the stage as not tested, not reached, censored, unavailable, or otherwise classified by the registered protocol. Absence of downstream evidence must never be converted into a favorable or unfavorable conclusion about that downstream layer.
“The study followed its frozen authority rules and stopped at the Reference Gate when one required cross-source relationship failed the preregistered binding condition.”
“The model failed,” “retrieval was uneconomic,” or “the Compression Dividend was negative” when the benchmark stopped before those stages were reached.
Evaluation-evidence rule: A valid evaluation record must preserve the deepest stage actually reached, every gate decision encountered, all material failures and deviations, and every downstream question left untested. Completing a registered process does not guarantee a favorable result, and a favorable result does not automatically confer the formal evidence state Supported.
Statement-Level Classification
Finding labels identify how each individual statement in the compliance record was produced. They prevent observations, calculations, interpretations, proposals, and evidence gaps from being combined into an unqualified conclusion.
Use only these finding labels: Documented, Calculated, Inferred, Proposed, and Unknown. Do not substitute informal confidence labels or use a finding label as a formal evidence state.
Finding Label
The statement is directly supported by an identified document, configuration, log, test, observation, artifact, or measurement record.
Boundary: Documentation establishes that a record exists. It does not automatically establish accuracy, independence, requirement satisfaction, or validated performance.
Finding Label
The statement results from an explicit calculation applied to documented inputs using a disclosed formula, unit, allocation, or transformation.
Boundary: Preserve the source inputs, formula, units, assumptions, uncertainty, and sensitivity to allocation choices.
Finding Label
The statement is an interpretation derived from documented or calculated evidence rather than a directly observed fact.
Boundary: State the reasoning, alternative explanations, scope, uncertainty, and evidence that could challenge the inference.
Finding Label
The statement presents a requirement candidate, design, corrective action, hypothesis, prediction, target, or recommendation not established by current evidence.
Boundary: Proposed controls must not be described as canonical unless adopted by the governing authority.
Finding Label
The available evidence does not support a reliable documented, calculated, or inferred statement within the assessment boundary.
Boundary: Use Unknown when required evidence, provenance, configuration, units, telemetry, access, or scope is unavailable.
Requirement: The applicable requirement ID and authority version.
Statement: The smallest independently assessable observation, calculation, inference, proposal, or unknown.
Label: Documented, Calculated, Inferred, Proposed, or Unknown.
Support: Evidence ID, source record, calculation, or assessment method.
Scope: System, version, configuration, workload, constraints, period, and evidence boundary.
Limitations: Missing data, uncertainty, conflicts, alternative interpretations, and transfer restrictions.
| Combined statement to avoid | Separated compliance findings |
|---|---|
| “The system contains a Razor controller and is therefore compliant, efficient, and environmentally beneficial.” | Documented: A named controller version exists. Inferred or Unknown: Whether the controller satisfies the complete applicable framework requirements. Unknown: Efficiency without a valid comparative evaluation and total-cost record. Unknown: Environmental benefit without direct telemetry or a defensible accounting model. |
Finding-label rule: Finding labels classify individual statements. They do not assign a formal evidence state to a claim and do not independently create a compliance, certification, or validation decision.
Claim-Level Classification
Formal evidence states describe the current evidentiary status of a defined and versioned claim. They do not describe how an individual statement was produced and should not be assigned merely because an implementation satisfies a framework requirement.
Use only these formal evidence states: Proposed, Testing, Provisionally Supported, Supported, Challenged, Inconclusive, and Retired.
| Evidence state | Meaning | Compliance boundary |
|---|---|---|
| Proposed | The claim has been stated in a testable form but has not completed the evidence process required for support. | Framework conformance may show that the claim and test requirements are documented; it does not establish the predicted result. |
| Testing | A registered evaluation, replication, or evidence-collection process is actively examining the claim. | Evaluation readiness or an active test does not imply that the predicted outcome has occurred. |
| Provisionally Supported | Available evidence supports the claim under a defined scope, but material limitations, restricted replication, boundary uncertainty, or unresolved questions remain. | The supporting system, workload, version, conditions, evidence limits, and re-evaluation needs must remain visible. |
| Supported | The claim has met the governing evidentiary requirements under its stated scope, including applicable protocol, quality, reproducibility, and adverse-evidence review. | Supported does not mean universal, permanent, certified, or transferable beyond the evaluated claim boundary. |
| Challenged | Credible evidence, replication failure, boundary failure, contradiction, or methodological concern materially conflicts with the claim or its current scope. | The challenge, affected scope, supporting evidence, review status, and required resolution should be recorded. |
| Inconclusive | The evidence is insufficient, ambiguous, mixed, conflicting, too uncertain, or methodologically incomplete for a support or challenge decision. | The record should identify the missing evidence, unresolved conflict, or corrective work required. |
| Retired | The claim is no longer active because it was withdrawn, superseded, merged, replaced, or removed from the current framework. | The historical claim, prior evidence state, retirement reason, decision authority, and successor claim should remain traceable. |
| Compliance finding | Formal evidence state | |
|---|---|---|
| Applied to | A defined assessment unit and applicable framework requirement. | A defined and versioned claim. |
| Question answered | Was the requirement satisfied within the assessed boundary? | What is the claim’s current evidentiary status? |
| Evidence needed | Requirement-specific design, implementation, operational, or process evidence. | Preregistered testing, quality results, total-cost evidence, failures, replication, and adverse-evidence review as applicable. |
| Automatic conversion? | No. Satisfying a framework requirement does not automatically support a performance claim. | No. State assignment requires the governing claim-review process. |
Evidence-state rule: A favorable conformance assessment, implementation, pilot, benchmark, publication, license, or author-created evaluation does not independently confer the state Supported. State changes must follow the governing review process and remain recorded in the Canonical Claims Register.
Requirement Gaps and Resolution
A nonconformity exists when an applicable framework requirement is not satisfied within the assessed boundary. Each nonconformity should identify the requirement, evidence, affected system, consequence, correction, corrective action, and verification needed for closure.
Nonconformity boundary: A requirement failure is not automatically a refutation of Robbie’s Razor, but it may invalidate a compliance statement, limit an evaluation, expose a system risk, or challenge a performance claim. Its consequence must be assessed rather than minimized.
| Record field | Required content |
|---|---|
| Nonconformity ID | Stable identifier, title, creation date, owner, status, and linked assessment record. |
| Requirement reference | Requirement ID, exact requirement text, authority version, applicability decision, and acceptance criteria. |
| Affected assessment unit | System, version, configuration, workload, constraints, measurement period, and evidence boundary. |
| Finding statement | Atomic description of the unmet condition with Documented, Calculated, Inferred, Proposed, or Unknown labels applied to supporting statements. |
| Supporting evidence | Evidence IDs, source records, logs, tests, configurations, observations, calculations, missing evidence, and limitations. |
| Consequence and scope | Affected requirements, claims, components, workloads, quality dimensions, risks, result records, and public statements. |
| Immediate correction | The immediate repair, containment, qualification, suspension, rollback, disclosure, or other action applied to the observed issue. |
| Cause analysis | Available evidence about why the nonconformity occurred, including process, design, implementation, evidence, version, or governance causes. |
| Corrective action | Action intended to address the cause and reduce recurrence, with owner, due date, dependencies, and required resources. |
| Verification method | Inspection, test, reproduction, configuration review, monitoring period, quality check, or other method used to verify correction and effectiveness. |
| Closure decision | Reviewer, decision date, evidence reviewed, remaining limitations, affected assessment status, and whether re-evaluation is required. |
Addresses the observed instance—for example, replacing a stale state record, correcting a mislabeled result, restoring a stop rule, or qualifying an unsupported public statement.
Addresses the contributing cause—for example, changing version controls, adding constraint tests, improving evidence capture, revising review procedures, or preventing stale-state recurrence.
An organization may use its own risk or severity system to prioritize nonconformities. Any such system should identify its scale, criteria, decision authority, and relationship to corrective action. It must be labeled as a local control and must not be presented as a canonical R-level.
Closure rule: A nonconformity is not resolved merely because an action was planned or code was changed. Closure requires evidence that the applicable requirement is now satisfied and that the affected compliance statement has been reviewed under the correct system version and boundary.
Assessment Lifecycle
A compliance finding applies only to the assessed framework version, system version, configuration, workload, constraints, evidence period, and requirement set. Versioning preserves that relationship and prevents an older finding from silently following a materially changed system.
Lifecycle boundary: A prior finding should not be described as current after a material change unless the change has been reviewed and the finding has been reaffirmed, qualified, or replaced.
| Version field | Required record |
|---|---|
| Assessment-record version | Stable assessment ID, record version, creation date, modification date, assessor, reviewer, and amendment history. |
| Governing-authority version | GC-MRD version, claim-register version, applicable framework pages, requirement set, and modification dates. |
| System and component versions | Model, software, prompts, controllers, memory schemas, retrieval indexes, tools, dependencies, infrastructure, and deployment environment. |
| Workload version | Task set, data sources, sampling, acceptance criteria, user population, difficulty distribution, and exclusions. |
| Evidence version | Evidence IDs, source versions, collection period, transformations, checksums, supersession, accessibility, and retention. |
| Finding and action versions | Requirement findings, nonconformities, corrections, corrective actions, closure records, and unresolved limitations. |
| Validity conditions | Effective date, assessment period, expiration or review date, approved use, excluded use, and re-evaluation triggers. |
GC-MRD, canonical claims, definitions, evidence states, finding labels, or applicable requirements change.
Model, software, prompt, controller, memory, retrieval, tools, infrastructure, permissions, or dependencies materially change.
Task class, data, scale, language, domain, user population, quality threshold, safety rule, or operating constraint changes.
A new evaluation, failed replication, incident, adverse finding, missing record, corrected calculation, or independent review becomes available.
A material nonconformity is corrected and the organization seeks closure or a revised compliance finding.
The defined review date, expiration period, surveillance event, or evidence-retention boundary is reached.
Examines a bounded change, nonconformity, requirement, component, or evidence correction when the remaining assessment boundary is demonstrably unchanged.
Reassesses the complete applicable requirement set when changes affect multiple components, the system boundary, quality gate, workload, evidence integrity, or governing authority.
Record-preservation rule: Do not silently overwrite an expired, qualified, challenged, superseded, or corrected assessment. Preserve the prior version and add the new decision, evidence, reason, date, and reviewer as a traceable update.
16. Review and Decision Independence
Independent review can strengthen confidence in an assessment by examining whether the declared requirements, evidence, methods, calculations, findings, and limitations are supported by the available record. It does not automatically convert a finding into certification or a claim into the formal evidence state Supported.
| Review form | Reviewer relationship | Permitted interpretation |
|---|---|---|
| Self-assessment | Performed by the assessed organization, implementation team, or framework originator. | An internally produced conformance record whose origin and limitations must be disclosed. |
| Second-party review | Performed by a customer, funder, licensee, contracting party, or other interested stakeholder. | A stakeholder review, not an independent third-party determination. |
| Independent third-party review | Performed by a qualified party outside the assessed implementation and decision chain, subject to disclosed conflicts. | An external review of a defined assessment record. Its authority remains limited to the stated scope. |
| Certification | Requires a documented certification scheme, requirements, qualified decision authority, surveillance process, and rules for granting, maintaining, suspending, and withdrawing status. | The term must not be used unless that complete process actually exists and applies to the assessed unit. |
Every review record should identify:
Confirm which framework requirements applied, which were excluded, and whether each conclusion follows from the stated evidence.
Examine provenance, calculations, instrumentation, missing data, contradictory records, and the separation of observation from inference.
Check whether public statements remain inside the tested system boundary, result record, evidence state, and domain-transfer limits.
Author-and-validation disclosure: Robbie George is the originator of Robbie’s Razor and the associated evaluation framework. Author-created tools, examples, implementations, and self-assessments must be distinguished from independent testing and replication. Independent review may confirm, qualify, challenge, or find the record inconclusive; it does not erase dissent, uncertainty, conflicts, or untested boundaries.
17. Applicability and Generalization
A conformance or performance result is limited to its registered assessment unit. Success in one model, workload, domain, language, scale, configuration, or operating environment cannot be generalized to another without a new applicability analysis and, when performance is at issue, a new empirical test.
Architecture-agnostic does not mean result-agnostic. The compliance framework and evaluation method may be applicable across multiple architectures, but a finding from one architecture does not establish the same outcome for another.
Model family, version, quantization, controller, prompts, memory architecture, tools, retrieval system, or integration design.
Task family, domain, difficulty, language, modality, sequence length, recursion depth, data distribution, or acceptance criteria.
Hardware, infrastructure, concurrency, batching, geography, security controls, privacy rules, or production constraints.
Instrumentation, telemetry access, observation period, missing-data conditions, provenance quality, or availability of accepted-outcome records.
| Transfer question | Required treatment |
|---|---|
| Do the framework requirements remain applicable? | Perform a new applicability and conformance review against the changed assessment unit. |
| Does the system retain its earlier implementation maturity? | Verify that the relevant controls, records, interfaces, and safeguards still exist and function under the new configuration. |
| Does an earlier performance result still apply? | Preregister and run a new evaluation under the Razor Evaluation Protocol. Do not inherit the earlier result by assumption. |
A transfer review should preserve:
Conformance transfer and performance transfer are separate decisions. A system may remain conformant to documentation requirements while its claimed performance remains Unknown, Testing, Challenged, or Inconclusive in the new domain.
18. Environmental Evidence Discipline
Conformance to environmental evidence requirements means that a system’s environmental statements are properly bounded, measured, calculated, and labeled. It does not mean that the system has demonstrated an environmental benefit.
Prohibited shortcut: Token, latency, FLOP, or cache reductions must not be converted automatically into energy savings, cooling savings, water savings, carbon reduction, or emissions reduction. When the necessary telemetry or defensible accounting model is unavailable, the environmental finding label is Unknown.
An environmental comparison should identify the relevant system boundary and include, where material:
Hardware, device count, utilization, idle allocation, quantization, concurrency, batching, run duration, and failed or retried executions.
Data-center location, infrastructure overhead, cooling design, measurement period, allocation method, and boundaries between device and facility consumption.
Energy supply, temporal and geographic factors, emissions factors, renewable-energy claims, uncertainty, and whether accounting is operational or life-cycle based.
Direct and indirect water boundaries, cooling-water allocation, hardware manufacture, replacement cycles, and embodied impacts when included in the claim.
| Quantity | Example units | Boundary rule |
|---|---|---|
| Power | W or kW | An instantaneous or averaged rate; it is not energy unless integrated over time. |
| Energy | J, Wh, or kWh | State whether the measurement covers devices, supporting infrastructure, or the complete facility allocation. |
| Water | L or gallons | Identify direct consumption, withdrawal, cooling allocation, and any indirect electricity-related estimate separately. |
| Greenhouse-gas emissions | kg CO2e | Disclose emissions factors, geography, time basis, allocation method, scopes included, and uncertainty. |
| Embodied impact | Declared life-cycle units | Keep manufacture and life-cycle estimates separate from directly measured operational consumption. |
For the complete measurement-first treatment, see Environmental Impact & Computational Ecology. Environmental conformance means the evidence boundary is explicit and the claim does not exceed it—not that a favorable environmental result has already been established.
19. Commercial and Evidentiary Separation
Licensing governs permission, access, attribution, commercial use, protected materials, and contractual obligations. Compliance assessment determines whether a defined assessment unit satisfies specified framework requirements. Empirical evaluation determines whether a performance proposition is supported under registered test conditions. These are separate processes.
| Process | Primary question | What it does not establish |
|---|---|---|
| Licensing | Does the party have permission to use the applicable intellectual property, materials, services, or commercial implementation rights? | Effectiveness, efficiency, quality, environmental benefit, certification, or a favorable evidence state. |
| License conformance | Is the licensee following the applicable contractual conditions, permitted uses, attribution rules, reporting duties, and restrictions? | Framework conformance or validated technical performance. |
| Framework conformance | Does the defined assessment unit satisfy the applicable GC-MRD-v2.0 and compliance-framework requirements? | That a performance proposition has passed empirical testing. |
| Empirical evaluation | Does a preregistered claim survive equivalent-quality testing, total-cost analysis, failure review, and the registered evidence boundary? | Commercial permission, license compliance, or certification. |
A party may obtain permission to conduct a pilot or use licensed materials without receiving a favorable performance determination. Performance claims remain subject to preregistration, testing, result recording, and evidence-state review.
Accepting a license, paying a fee, integrating an implementation, or deploying a tool demonstrates access or adoption. None of those events demonstrates effectiveness.
When licensing and evaluation occur together, public descriptions should disclose:
Environmental condition: A licensing agreement may contain environmental reporting, reciprocity, or stewardship obligations. Contractual compliance with those provisions is not evidence of energy, water, carbon, cooling, or emissions savings. Environmental performance requires the separate telemetry and accounting controls defined in this framework.
20. Public Reproducibility Layer
The public benchmark system and GitHub repository support reproducible evaluation. They may preserve test assets, schemas, examples, result-record structures, and implementation materials. They do not replace the governing canonical authority or the formal evidence-state decision process.
Authority boundary: GC-MRD-v2.0 defines the governing framework. The Canonical Claims Register tracks claims and evidence states. GitHub is the public reproducibility layer—not the canonical authority.
| Layer | Primary function | Boundary |
|---|---|---|
| GC-MRD-v2.0 | Defines canonical concepts, requirements, scope, terminology, and governing authority. | Canonical publication does not itself validate a performance claim. |
| Canonical Claims Register | Tracks registered claims, formal evidence states, boundaries, and review status. | A listed claim is not necessarily supported; its recorded evidence state controls interpretation. |
| Benchmark Hub | Organizes evaluation pathways, benchmark classes, quality gates, and reproducibility guidance. | Benchmark availability does not demonstrate that a system passed it. |
| GitHub repository | Preserves versioned public assets that can support testing, review, and replication. | Code publication, repository activity, stars, forks, indexing, or reuse do not establish effectiveness. |
| Result record | Preserves the registered test, observations, calculations, quality outcome, failures, missing data, and analysis. | One result record remains limited to its system and evidence boundary. |
Before a website assessment claims that repository alignment is complete, the cited repository version or commit should be inspected for:
Authority: GC-MRD-v2.0 identifier, governing links, version references, and deprecation of obsolete authority language.
Evidence systems: Current finding-label and formal evidence-state enumerations kept as separate fields.
Assessment fields: System boundary, workload, baseline, quality gate, CEMR measures, total costs, failures, and missing-data procedures.
Claim restrictions: Domain-transfer limits, environmental telemetry boundaries, reasoning-privacy rules, and non-certification language.
Version discipline: A compliance statement must cite the repository URL, branch or release, commit identifier when available, retrieval date, relevant asset paths, and any differences between the website authority and the inspected repository snapshot. Do not describe website–repository alignment as complete unless that comparison has actually been performed.
21. From Canonical Authority to Evidence-State Review
A Robbie’s Razor compliance assessment should follow the evidence architecture in order. The process begins by identifying the governing canon and applicable requirements, then establishes the assessed system and its reference boundary before determining whether implementation, evaluation, performance, or evidence-state conclusions are justified.
Not every assessment requires a performance benchmark. A conformance-only review may stop after determining whether applicable framework requirements are satisfied. But whenever a technical performance, quality, efficiency, reuse, stability, or Compression Dividend claim is asserted, the assessment must verify that the applicable Reference Gate passed before target construction and that the downstream evaluation followed the registered protocol.
Complete Governance Path
Canonical Authority → Applicable Requirements → Assessment Boundary → Reference Architecture → Reference Gate → Implementation Review → Evaluation Lock → Quality Gate → Result Layer → Evidence-State Review
Upstream Reference Architecture
Metrology for Meaning™ defines the architectural problem that sits upstream of evaluation: how a governed system establishes identity, provenance, relationships, versions, rights, and authority strongly enough for later preservation and reconstruction to be measured against a stable reference.
Compliance therefore includes a new question whenever governed reference matters: Was the reference architecture sufficiently defined and followed before the system was evaluated?
Invariant Reference → Compression → Expression → Memory → Recursion
Invariant Reference is an upstream evaluation condition. It does not replace or add a fifth phase to canonical RC-01.
Conformance Path
Determine whether applicable framework requirements, reference controls, documentation, provenance, versioning, Quality Gate procedures, evidence controls, failure rules, and corrective-action processes exist and are supported by attributable evidence.
Performance Path
Performance claims require a preregistered empirical evaluation. Reference, quality, cost, reuse, stability, environmental, or other performance outcomes cannot be inferred merely because the required process exists.
A compliant evaluation may be required to stop.
Procedural conformance is demonstrated by following the frozen rules—not by forcing the experiment to reach a favorable model or economic result.
Lock 1
Authority sources, selectors, precedence, required values, normalization, equivalence, relationship binding, rights, correction policy, censorship rule, and target-construction procedure were frozen before authority was audited.
Lock 2
Prediction, baseline, intervention, Quality Gate, metrics, cost boundary, sample design, success threshold, failure conditions, analysis plan, and result rules were frozen before comparative outcomes were inspected.
Gate 1
Can the governing authority package establish a sufficiently coherent state from which the benchmark target may validly be constructed under the frozen Reference Contract?
Gate 2
Once a valid target exists, did the compared conditions satisfy the same preregistered quality and acceptance requirements strongly enough for downstream efficiency comparison?
Study 008 · Compliance Example
Study 008 captured all required governed leaf values but encountered one required cross-source canonical relationship that could not satisfy the frozen authority-binding rule.
Because the preregistered Reference Contract prohibited post-hoc normalization, silent correction, semantic substitution, and trademark removal for that relationship, the study correctly stopped before hidden-target construction and downstream model or economic evaluation.
The authority discrepancy was a benchmark outcome. Following the frozen stop rule was protocol-conformant behavior, not evidence that the evaluated model failed.
Layer 1
Records whether the Reference Gate established a valid governed target or censored downstream evaluation.
Layer 2
Records what happened after a valid target existed and the evaluated conditions were judged against the Quality Gate.
Layer 3
Records total-cost, reuse, break-even, Dynamic Reuse Frontier, or Compression Dividend findings only when the upstream gates permit that comparison.
| Step | Layer | Required Action | Output |
|---|---|---|---|
| 1 | Canonical authority | Identify GC-MRD-v2.0, applicable claims, definitions, scope, controlling terminology, and supersession rules. | Authority record. |
| 2 | Applicable requirements | Determine which canonical and local requirements apply and preserve exclusions or not-applicable decisions. | Requirement register. |
| 3 | Assessment boundary | Register the system, version, configuration, workload, constraints, period, dependencies, assessor, and evidence boundary. | Locked assessment unit. |
| 4 | Reference architecture | Identify authority surfaces, identity rules, provenance, versions, relationships, rights, normalization, equivalence, correction, and binding requirements where governed state matters. | Reference Contract or reference-conformance record. |
| 5 | Reference Gate | For governed empirical testing, determine availability, selection, completeness, coherence, required binding, rights, and target-construction authorization. | Governed state or authority-layer stop. |
| 6 | Implementation review | Inspect CEMR components, controls, interfaces, versioning, provenance, failure handling, evidence capture, and corrective-action readiness. | Requirement-level conformance findings. |
| 7 | Razor Auditor | Diagnose documentation, evaluation readiness, CEMR structure, total-cost coverage, reference gaps, quality controls, and failure conditions. | Diagnostic findings—not certification. |
| 8 | Lab Evaluation Protocol | When performance is asserted, preregister the Reference Lock, Evaluation Lock, target procedure, baseline, intervention, Quality Gate, metrics, costs, failures, and analysis. | Frozen confirmatory evaluation plan. |
| 9 | Benchmark execution | Proceed only through stages authorized by prior gates. Preserve quality outcomes, costs, failures, censored stages, deviations, and missing evidence. | Authority, model / quality, or economic result. |
| 10 | Result record | Record the deepest valid stage reached, gate outcomes, target status, observations, calculations, failures, stages not reached, and limitations. | Versioned bounded result. |
| 11 | Replication and review | Reproduce or independently review the relevant authority, model, quality, economic, and conformance findings while preserving changed conditions. | Replication or review record. |
| 12 | Evidence-state review | Evaluate the complete record using the formal evidence-state system while preserving contrary findings, censorship, uncertainty, and scope limitations. | Proposed, Testing, Provisionally Supported, Supported, Challenged, Inconclusive, or Retired. |
Before beginning a compliance or performance pilot, the participating team should be able to provide:
Decision boundary: Completing the pathway does not guarantee a favorable finding. A valid assessment may conclude requirement met, requirement not met, authority-layer censored, Quality Gate failed, higher total cost, negative reuse economics, no material difference, insufficient evidence, failed replication, challenged proposition, or another properly bounded outcome.
Fail-Closed Governance
If the authority layer cannot establish a valid target, compliance requires that the record preserve that limitation rather than invent a target. If the Quality Gate fails, compliance requires that efficiency interpretation stop. If economics were not measured, compliance requires that no Compression Dividend be claimed. The framework rewards correct boundary enforcement—not favorable conclusions.
Compliance Spine
Canon → Requirements → Reference → Conformance → Evaluation → Result → Review → Evidence State
The Razor Auditor and related diagnostic tools may organize readiness findings, evidence gaps, and requirement questions. They do not provide certification, independent validation, or an automatic formal evidence-state decision.
22. Frequently Asked Questions
These answers clarify what compliance, conformance, evaluation readiness, implementation maturity, evidence maturity, and validated performance mean under GC-MRD-v2.0.
Compliance means that a defined assessment unit satisfies specified, applicable framework requirements within a declared evidence boundary. The assessment must state whether it addresses framework conformance, evaluation readiness, implementation maturity, evidence maturity, or validated performance.
No. Certification requires a documented certification scheme, qualified decision authority, defined surveillance process, and rules for granting, maintaining, suspending, and withdrawing status. This framework must not be described as certification unless those conditions actually exist and apply.
Not as a controlling compliance or certification scale. Earlier R0–R5 and numerical scoring language is historical and noncontrolling unless exact level definitions, requirements, decision rules, and authority are formally established under GC-MRD-v2.0.
The required unit is: System + Version + Configuration + Workload + Constraints + Measurement Period + Evidence Boundary. A conclusion that omits these fields is too broad to support a reproducible compliance determination.
No. Building a tool, publishing code, using a prompt, integrating a controller, deploying a memory system, licensing an implementation, or appearing in GitHub demonstrates implementation, publication, access, or adoption—not validated effectiveness.
A shorter, faster, or cheaper output is not more efficient if it fails the same acceptance standard. Correctness, completeness, safety, usefulness, constraint compliance, verification burden, correction burden, and memory fidelity may all be material quality requirements.
Finding labels classify individual statements as Documented, Calculated, Inferred, Proposed, or Unknown. Formal evidence states classify registered claims as Proposed, Testing, Provisionally Supported, Supported, Challenged, Inconclusive, or Retired. A Documented observation is not automatically a Supported claim.
No. The framework evaluates observable inputs, outputs, tool calls, stored state, retrieval behavior, execution results, telemetry, and accepted outcomes. Private chain-of-thought is not required and should not be claimed as available when it is not.
No. Token, latency, FLOP, or cache changes cannot be converted automatically into energy, cooling, water, carbon, or emissions savings. Environmental conclusions require direct telemetry or a defensible accounting model with explicit hardware, utilization, batching, geography, energy-supply, cooling, and measurement boundaries.
No. Licensing governs permission, access, attribution, commercial use, and contractual obligations. License conformance, framework conformance, and empirical performance are separate determinations.
GitHub is the public reproducibility layer for versioned benchmark and evaluation assets. GC-MRD-v2.0 remains the governing canonical authority, while the Canonical Claims Register tracks formal claim status. Repository publication or activity does not validate a claim.
Not automatically. Success in one model, version, workload, domain, language, scale, or environment cannot be generalized to another without a new applicability analysis and, when performance is asserted, a new preregistered test.
No. The Razor Auditor is a diagnostic framework, and its interactive interface is experimental. It can organize questions, evidence boundaries, and labeled findings, but it does not provide certification, independent validation, or an automatic evidence-state decision.
Failure may include an unmet quality threshold, missing required evidence, material nonconformity, uncontrolled baseline differences, higher total cost, degraded accepted outcomes, contradictory results, failed replication, an exceeded environmental boundary, or an unsupported public claim.
For testing requirements, see the Razor Evaluation Protocol. For diagnostic preparation, see the Razor Auditor. Formal claims and evidence states should be checked against the Canonical Claims Register.
23. Authorship and Validation Disclosure
Robbie George is a National Geographic–published nature photographer, author, and creator of the Grand Compression Cosmology, Robbie’s Razor, and the Razor Auditor evaluation framework.
His work examines how compression, expression, memory, recursion, identity, provenance, and constraint interact across reasoning systems and natural systems. The Robbie’s Razor Compliance Framework provides a structured method for distinguishing documented conformance from implementation activity, empirical performance, commercial adoption, and formal evidence maturity.
Author-and-validation disclosure: Robbie George is the originator of Robbie’s Razor and the associated evaluation framework. Author-created tools, examples, and implementations should be distinguished from independent testing and replication. Authorship, publication, implementation, or licensing does not establish that a technical or performance claim has been independently validated.
This page is governed by GC-MRD-v2.0. Compliance findings remain limited to the declared assessment unit, evidence boundary, applicable requirements, review type, and recorded version.
Robbie’s Razor Compliance Framework · Document Version 2.0 · Governing Authority: GC-MRD-v2.0
This is only visible to you because you are logged in and are authorized to manage this website. This message is not visible to other website visitors.
Click on any Image to continue
This means you can use the camera on your phone or tablet and superimpose any piece of nature art onto a wall inside of your home or business.
To use this feature, Just look for the "Live Preview AR" button when viewing any piece of nature art on this website!
Join the collector list for your first-order discount, new wildlife releases, and occasional field notes.
