| Integrity surface | Current requirement | Claim boundary |
| Claim typing | Material empirical, causal, formal, operational, legal-regulatory, normative, and metaphysical-horizon claims declare their evidence and authority boundaries. | The protocol does not make every legal or normative commitment physically falsifiable. |
| Warrant-domain bridge | A material conclusion identifies the domain of the offered warrant and any bridge required when the conclusion crosses scientific, engineering, legal-regulatory, institutional, or normative domains. | Authority, compliance, certification, performance, and rhetoric cannot silently change claim type. |
| Dependency integrity | Starting assumptions, definitions, models, thresholds, and inherited sources are versioned; material changes trigger re-derivation. | Silent retrofitting is prohibited. |
| Revision trigger | A claim identifies evidence or conditions that would force revision, narrowing, rerun, or retirement. | Fluency and coherence are not external confirmation. |
| Capability claim integrity | A material capability term is operationally defined and bound to observable criteria, mechanism or system composition, evidence, validity conditions, alternatives, a falsifier, evidence maturity, permitted wording, and explicit nonclaims. | Neither component reduction nor anthropomorphic language settles the capability claim. |
Source-boundary rule: If this compact standard conflicts with the RippleLogic Canon, the Canon controls.
## Frozen Evaluation Binding and Milestone Claim Discipline
Before consequential evaluation, the run freezes and versions the decision question, system boundary, configuration, evidence schema, stakeholder scope, rights interpretation, scenario families, thresholds, uncertainty treatment, weighting protocol, control requirements, stopping conditions, and authorization pathway. For a confirmatory operator or performance test it also freezes a finite, enumerated or formally bounded admissible falsification family and a stopping/attribution rule. A material post-result alteration creates a new run or declared revision branch; it cannot turn a failed original prescription into a successful original test.
Implementation milestones are classified narrowly. Successful formal derivation, compilation, synthesis, simulation, hardware implementation, or integration may defeat a specific impossibility hypothesis, but it does not prove empirical superiority, domain validity, physical safety, ontology, rights compatibility, or deployment readiness. Claims must name the exact falsification criterion tested and the alternatives that remain open.
## Purpose
This compact standard defines the methodological integrity discipline for MathGov and RippleLogic. It adopts the bounded principle that claim-bearing elements must not survive merely because they are plausible, fluent, approved, compliant, or locally useful. A material claim must declare what kind of claim it is, what it depends on, what would force revision, what alternatives remain open, and what downstream elements must be rerun if the foundation changes.
It is not a sixth gate. It does not replace Reality Grounding, RF/NCRC, TRC, CSV, SGP, RLS, PC-AEP, domain science, or external validation.
## Adopted principles and bounded non-claims
| Field | Required content |
| claim_or_component | The claim, definition, threshold, operator, indicator, model, SGP interpretation, gate decision, validation result, or public release claim under review. |
| claim_type | empirical, causal, formal, operational, legal_regulatory, normative, or metaphysical_horizon. The display labels “legal-regulatory” and “metaphysical-horizon” MAY be used in prose; validator-facing records MUST use legal_regulatory and metaphysical_horizon. |
| claim_domain | The primary authority domain in which the conclusion is asserted: scientific_empirical, engineering_operational, formal_mathematical, legal_regulatory, normative_ethical, institutional_governance, commercial_descriptive, anthropomorphic_social, or metaphysical_horizon. A materially mixed conclusion SHOULD be split into separately typed claims. |
| warrant_domains | One or more domains from which support derives. Multiple domains MAY support one claim, but each material cross-domain relationship requires its own bridge record. |
| cross_domain_bridges | Zero or more bridge records. Each record contains from_warrant_domain, to_claim_domain, bridge_status, bridge_proposition, bridge_evidence_or_rationale, uncertainty, validity_or_jurisdiction_boundary, and revision_or_refusal_condition. |
| dependency_position | Where the claim sits in the cascade, standard, SGP flow, workbook, validation protocol, or public release surface. |
| starting_assumptions | Assumptions, definitions, priors, sources, thresholds, scope boundaries, or model premises that carry the claim. |
| definition_or_operator_used | The material definition, operator, threshold, indicator, or procedure being applied. |
| necessity_or_alternative_check | Whether necessity is claimed, what alternatives remain plausible, and why the stronger claim is or is not warranted. |
| evidence_or_test_surface | The observation, measurement, replication, derivation, simulation, formal proof, expert review, stakeholder challenge, or audit surface used. |
| falsification_or_revision_trigger | What result, evidence, challenge, failure, or domain change would force revision, narrowing, escalation, or refusal. |
| uncertainty_or_confidence_method | How uncertainty, confidence, model limits, disagreement, or unresolved evidence is represented. |
| downstream_dependencies | Gates, scores, SGP outputs, claims, controls, authority actions, or release statements affected if this element changes. |
| re_derivation_scope_if_changed | Local patch, threshold update, gate rerun, TRC reopening, CSV rerun, SGP rerun, RLS recalculation, release versioning, or full refusal. |
| reviewer_status | reviewer-visible, contested, independently checked, domain-expert-warranted, or pending. |
| required_claim_action | proceed, narrow, control, redesign, escalate, or refuse. |
| operational_definition (conditional) | The measurable functional meaning of the capability term in the pinned configuration and domain. |
| observable_criteria (conditional) | The observations that would count as demonstration, non-demonstration, or failure of the capability. |
| mechanism_or_system_composition (conditional) | The components and interactions that instantiate the claimed capability without assuming any single component supplies the whole. |
| evidence_surface (conditional) | The logs, trials, benchmarks, traces, inspections, or other evidence that support the bounded claim. |
| validity_conditions (conditional) | Configuration, domain, environment, time, operator, and control conditions inside which the claim is licensed. |
| alternative_explanations (conditional) | Simpler or rival explanations such as scripting, operator intervention, memorization, benchmark fit, or interface effects. |
| falsification_or_revision_trigger (conditional) | Reuses the general falsification_or_revision_trigger field. For a capability claim, that same field must also identify the observation or boundary violation that would narrow, revise, suspend or refute the capability claim. Do not serialize a second property with the same name. |
| evidence_maturity_stage (conditional) | Definition/derivation, computational realization, implementation conformance, projection/calibration lock, controlled empirical contact, operational qualification, or outcome/requalification evidence. |
| permitted_claim (conditional) | The strongest wording licensed by the present evidence and maturity stage. |
| explicit_nonclaims (conditional) | Stronger inferences not licensed, including consciousness, personhood, intrinsic goals, moral agency, generality, unrestricted autonomy, safety, legality, or authority where applicable. |
| target_of_understanding (conditional) | The target object, process, system, proposition, or domain state that is claimed to be understood. |
| relation_claimed (conditional) | The relation asserted, such as explanation, prediction, counterfactual manipulation, intervention, correction, or transfer. |
| distance_from_training_or_known_exemplars (conditional) | How the test distinguishes transfer or novel application from retrieval, memorization, contamination, or benchmark fit. |
| scaffolding_and_tools (conditional) | Prompts, retrieval, memory, tools, human assistance, environmental feedback, or other scaffolding required for the demonstrated performance. |
| transfer_conditions (conditional) | The contexts, perturbations, reduced-scaffolding conditions, or domain shifts across which the understanding claim is expected to hold. |
## Dependency-localized failure propagation
If a premise, primitive, definition, operator, evidence source, control, or inherited dependency fails, every materially dependent gate result, score, SGP output, authorization, validation claim, or public statement must be reopened, narrowed, suspended, rerun, or withdrawn. The record must identify the dependency path and re-derivation scope.
A component with an independent evidence and derivation path does not fail merely because another part of the framework fails. This rule prevents both monolithic immunity—protecting dependent claims after foundation failure—and indiscriminate whole-framework rejection—discarding independently supported components without testing their actual dependencies.
## Taxonomy, Formalization and Engineering Claim Discipline (Normative)
Orthogonality, independence, irreducibility, optimality, observability and controllability claims must state their exact mathematical or operational meaning, object, assumptions, scope and falsifier. Conceptual distinction, uncorrelated variables, statistical independence, causal separation and non-duplicated accounting are not equivalent. A useful architectural vocabulary is not a proved theorem.
Do not claim that seven dimensions/scopes are maximally complete or irreducible from symmetry, selected examples or an uncalibrated sum of loss criteria. Preregister plausible merges/splits and report the trade-offs separately. An aggregation rule, unit test or constrained counterexample establishes only its stated proposition.
Production readiness, zero data loss, privacy, cryptographic security, exact recovery, real-time performance and successful hardware deployment require exact executable artifacts and corresponding evidence. Source code, mock logs, invented signatures and illustrative scenario parameters do not establish these claims. Cryptographic verification proves a declared formal relation under assumptions, not measurement truth, lawful authority, empirical welfare or absence of omitted harms.
The proposed control envelopes, degraded-mode and privacy interfaces strengthen existing records. The speculative susceptibility formula, automatic 90-percent counter-injection, multiplication-based identity commitment, sacred quorum/latency constants and biosphere/light-cone identity are not adopted. Research branches preserve failed tests and must not redefine success after observing outcomes.
## Status values
| Claim type | Example | Minimum discipline |
| Empirical | “Injury rates decreased after the intervention.” | Requires evidence contact, baseline, uncertainty, and alternative-explanation review. |
| Causal | “The policy caused the decrease.” | Requires the claim-specific causal identification plan and its supported claim boundary. A positive pre/post change may coexist with a harmful incremental effect; mechanism language or a comparator recommendation alone does not identify causation. Without adequate identification, restrict the conclusion to supported descriptive, predictive or procedural claims. |
| Formal | “CVaR was computed by the declared algorithm.” | Requires definitions, assumptions, formula, inputs, and reproducible calculation surface. |
| Operational | “The system is operationally autonomous within the declared pilot envelope.” | Requires an operational definition, observable criteria, system composition, evidence trace, alternatives, validity conditions, falsifier, explicit nonclaims, controls, and authority boundary. |
| Legal-regulatory | “This agency may lawfully authorize the trial.” | Requires current authority, jurisdiction, applicability analysis, interpretation status, and challenge or review path. |
| Normative | “This rights floor is adopted as non-compensatory.” | Requires declared ethical commitment, consistency check, rights compatibility, and challenge pathway. |
| Metaphysical horizon | “AIU language is used as a humility horizon.” | May guide meaning and restraint, but creates no Tier 1-3 evidence or gate authority. |
| Operational / institutional | “The AI system occupies an instrumental tool-role in this workflow.” | Requires the deploying actor, assigned ends, objective and permission sources, responsibility and control arrangement, and explicit nonclaims concerning capability, sentience, safety, moral status, and authority. |
| Functional capability | “The configured system functionally understands target T in domain D for relation R.” | Requires configuration identity, target and relation, evaluation conditions, scaffolding, novel or transfer tests, alternatives, failure boundary, and explicit nonclaim of phenomenal understanding. |
## Admissible Alternative Construction and Robustness Adjudication
An alternative construction blocks unique selection only when it is evidence-supported, selection-material, independently motivated rather than invented after result inspection, and accepted through a declared adjudication process.
The record SHALL identify the alternative, evidence basis, domain validity, independence from the interested option owner, expected affected calculations, selection effect, reviewer, disposition, and reopen condition. Rejected alternatives SHALL remain visible with rationale.
The Canonical Robustness Module Registry is finite for a release. New domain-mandated modules may be added only through a versioned rule or declared domain standard; an analyst cannot create an unlimited veto set after seeing results. This selection rule does not itself define a theory-level falsification family: confirmatory operator attribution uses the separately frozen finite or formally bounded family and stopping rule. Unexamined alternatives leave attribution unresolved; they do not annul a failed locked prescription or justify an unqualified performance claim.
A module marked NOT_TRIGGERED_WITH_RATIONALE requires the trigger examined, evidence basis, reviewer status, and reopen condition. REQUIRED_NOT_EVALUATED is distinct from not triggered and blocks unique framework selection.