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 Claim Was Tested
Evaluation evidence shows what happened when a defined system and intervention were tested under registered conditions. It is required for claims about quality, resource use, cost, stability, memory fidelity, environmental effects, or other performance outcomes.
The governing empirical method is the Razor Evaluation Protocol. A compliance assessment may verify whether that method was followed, but it should not rewrite the empirical result or replace the formal evidence-state process.
| Evaluation element | Required evidence | Conformance question |
|---|---|---|
| Preregistration | Time-stamped prediction, primary outcome, quality threshold, success threshold, failure conditions, analysis plan, observation period, and missing-data procedure. | Was the decision rule fixed before comparative results were inspected? |
| System boundary | System, version, configuration, workload, constraints, measurement period, evidence boundary, baseline, and intervention. | Was the tested unit complete, stable, and traceable? |
| Baseline integrity | Comparator rationale, matched access, equivalent configuration, fair tuning, identical acceptance criteria, and recorded differences. | Was the intervention compared with a defensible baseline? |
| Quality gate | Applicable quality dimensions, threshold, evaluation method, adjudication, accepted outcomes, failures, exclusions, verification, and correction. | Did each arm face the same acceptance standard? |
| Metrics and units | Operational definitions, units, source, collection procedure, aggregation, normalization, and limitations. | Were the claimed outcomes measured in a reproducible form? |
| Sample design | Population, sample size, task classes, repetitions, seeds, allocation, ordering, subgroups, stopping rule, and uncertainty treatment. | Was the sample sufficient for the registered decision? |
| Instrumentation | Equivalent logs, configuration snapshots, trial IDs, timestamps, state events, resource records, failure records, and instrumentation overhead. | Can the evaluation be reconstructed and checked? |
| CEMR results | Compression, expression, memory, recursion, cross-phase, quality, and boundary-condition results. | Were the four dimensions measured rather than assumed from architecture? |
| Total-cost results | Raw totals, cost categories, cost per attempt, cost per accepted outcome, allocations, exclusions, missing values, and sensitivity. | Did the result include material work across the complete system? |
| Failures and deviations | Failed predictions, invalid trials, safety stops, missing data, protocol deviations, exclusions, configuration drift, and corrective actions. | Were unfavorable and limiting results preserved? |
| Result record | Versioned decision, raw-data references, calculations, findings, limitations, alternative explanations, authorship, and review status. | Is the conclusion traceable to the registered test? |
| Replication and review | Reproduction, direct replication, independent review, adverse evidence, conflicts, changed conditions, and unresolved questions. | Has the result been examined beyond the original implementation team? |
The system boundary, baseline, quality gate, metrics, instrumentation, and decision rules are sufficient to begin a valid test.
The registered trials were executed and a versioned result record preserves the outcomes, failures, deviations, and limitations.
A separate formal evidence-state decision made after applicable protocol, replication, adverse-evidence, scope, and review requirements are satisfied.
Evaluation-evidence rule: Completing a test does not guarantee a favorable result, and a favorable result does not automatically confer a Supported evidence state. Preserve the registered scope and complete the governing evidence-state review.
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 Canon to Evidence-State Review
A compliance assessment should follow the system’s evidence architecture in order. The process begins with canonical requirements, defines the claim and assessment unit, diagnoses readiness, conducts preregistered testing where performance is asserted, preserves the result, and then submits the claim to replication and evidence-state review.
Canon defines → claims register tracks → Auditor diagnoses → protocol tests → GitHub preserves → replication checks → evidence states record
| Step | Layer | Required action | Output |
|---|---|---|---|
| 1 | Canonical authority | Identify GC-MRD-v2.0 requirements, applicable definitions, scope boundaries, and controlling terminology. | Applicable-requirements register. |
| 2 | Claims Register | Identify the proposition being assessed, its current evidence state, its owner, and its declared boundaries. | Registered claim and status record. |
| 3 | Assessment boundary | Register the system, version, configuration, workload, constraints, measurement period, and evidence boundary. | Locked assessment unit. |
| 4 | Razor Auditor | Diagnose documentation, measurement readiness, CEMR structure, total-cost coverage, evidence gaps, and failure conditions. | Labeled diagnostic findings—not certification. |
| 5 | Lab Evaluation Protocol | Preregister the prediction, baseline, metrics, units, quality threshold, success threshold, failures, analysis plan, observation period, and missing-data procedure. | Preregistered evaluation plan. |
| 6 | Benchmark execution | Run equivalent conditions, enforce the quality gate, capture total costs, preserve failures, and avoid favorable single-metric selection. | Raw observations and calculated measures. |
| 7 | Result record | Record accepted outcomes, provenance, calculations, missing data, exclusions, contradictions, failures, deviations, and limitations. | Versioned, reviewable result record. |
| 8 | Reproducibility assets | Preserve publishable methods, schemas, fixtures, code, hashes, versions, and machine-readable records in an appropriate repository. | Traceable replication package. |
| 9 | Independent replication | Repeat the registered test or a declared transfer test, preserving differences in system, workload, evidence access, and operating conditions. | Replication result and discrepancy record. |
| 10 | Evidence-state review | Evaluate the complete record using only the formal evidence states and preserve dissent, unresolved uncertainty, and domain 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 this pathway does not guarantee a favorable finding. A valid result may show conformance, nonconformity, no material difference, degraded quality, higher total cost, insufficient evidence, failed replication, or a challenged proposition. Those outcomes are part of the framework’s falsifiability discipline.
The Razor Auditor and related interactive tools are diagnostic interfaces. They do not provide certification, independent validation, or an automatic 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.
