# Architectural Review and Contribution Guide

Thank you for examining or contributing to the Continuum Paradigm. This guide protects the current canonical authority, complete-state representation, execution discipline, evidence chain, and certified claim boundaries.

## Standing of this guide

This file is procedural guidance. It does not create, revise, close, reopen, or supersede a scientific claim. If this guide conflicts with the active canonical distribution, the canonical authority order below controls.

## Required authority order

Review proposed changes against these documents in order:

1. [Canonical first principles](./01_CONTINUUM_CANONICAL_CHARTER.md)
2. [Mathematical derivation](./02_CONTINUUM_TECHNICAL_FOUNDATIONS.md)
3. [Execution and validation formality](./03_CONTINUUM_ENGINE_AND_VALIDATION_PROTOCOL.md)
4. [Closure and standing](./04_CONTINUUM_CLOSURE_AND_STANDING_MATRIX.md)
5. [Evidence and verification](./05_CONTINUUM_EVIDENCE_AND_VERIFICATION_RECORD.md)
6. [Critical-reader interpretation](./06_CONTINUUM_CRITICAL_READER_GUIDE.md)
7. [Phase execution](./07_CONTINUUM_PHASE_BY_PHASE_EXECUTION_GUIDE.md)
8. [Current status](./CURRENT_STANDING.md)

Only active package paths, current certificates, and current evidence records have execution or standing authority. File dates, legacy versions, explanatory prose, search metadata, and this contribution guide cannot override them.

## Classify the proposed change

Every contribution must identify one of these classes:

- **Editorial:** spelling, formatting, navigation, accessibility, or explanatory wording that does not alter equations, operators, inputs, outputs, evidence, or standing.
- **Implementation-preserving:** code or execution changes intended to reproduce an existing contract without changing its identity, method, tolerances, terminal rules, or retained state.
- **New execution contract:** a new input, method, coefficient, tolerance, domain, projection, or successor path. It must receive a new contract identity and cannot be reported as the existing run.
- **Claim-affecting:** a proposed change to a registered proposition, certification boundary, evidence linkage, falsification condition, prediction, or disposition. This requires coordinated updates to the controlling claim and evidence records; changing only narrative text is insufficient.

When uncertain, treat the change as contract- or claim-affecting until the authority review establishes otherwise.

## Preserve the complete state

Do not replace a retained structural state with one convenient scalar. A conforming implementation preserves every facet required by the controlling contract, including applicable node identities, shell states, relation sets, field objects, normalization, normalized densities, overlap components, entropy terms, selector state, and structured constituent objects.

The following may be properties or diagnostics of a retained state, but cannot silently replace it:

- one separation or spacing coordinate;
- one entropy, energy, force, or mass value;
- one overlap value;
- a sign-only or coupling-only result;
- a doubled atomic number or merged synthetic atom; or
- a conventional downstream label or comparator value.

A scalar-only replacement where complete retention is required is an `INVALID_REDUCTION_OF_COMPLETE_CONFIGURATION` failure, not a simplified successful result.

## Use terminal classifications exactly

Use the exact terminal code declared by the controlling contract. At the general review level:

- `RESOLVED` means that the declared contract reached a valid terminal result with its required retained state and artifacts.
- `EXCLUDED` means that a candidate, branch, or proposition was ruled out by the declared admissibility, rejection, or falsification rule.
- `NOT_EVALUABLE` means that a requested output is not defined or cannot be evaluated from the declared inputs and operators. It is not zero, a negative result, or permission to invent a substitute.

These general labels do not replace more specific canonical terminal strings such as `SEAM_RESOLVED_STATE_PAIR_RELATION_CLOSED` or `NOT_EVALUABLE_NO_PHYSICAL_INTERVAL`.

Do not rewrite a bounded, negative, excluded, falsified, or not-evaluable outcome as unfinished project work when its registered proposition has been adjudicated at that scope.

## Freeze every execution contract

Every production execution must declare and freeze:

1. contract ID;
2. objective;
3. canonical specification identity;
4. exact inputs;
5. equations and operators;
6. permitted perturbation;
7. coordinate and unit contract;
8. coefficient values or extraction rules;
9. domain and search bounds;
10. numerical or analytic method;
11. tolerances;
12. terminal states;
13. required artifacts;
14. comparator location;
15. comparator-access event; and
16. disposition rule.

A changed optimizer, grid, basis, restart scheme, precision, tolerance, coefficient, profile, domain, or boundary condition is a different contract. It must not retain the prior runtime identity.

## Maintain the comparator firewall

The required direction is:

> native complete structure → native relation, field, or selector consequence → frozen result → conventional representation or comparator

Target evidence may corroborate or falsify a frozen native result. It may not fit, tune, select, repair, or generate that result unless the active contract explicitly classifies it as an admitted input.

Record whether and when comparator access occurred. If a target was viewed before native freeze, do not describe the run as blind.

## Seal terminal runs

A terminal execution follows:

> detect terminal → record trigger → complete artifacts → hash → seal → stop

Do not repair a terminal run in place. A permitted successor requires a predeclared edge or a new contract identity, UID, transcript, artifacts, and seal. A post-terminal suggestion for another method is a future-contract candidate, not a modification of the sealed result.

## Retain evidence and provenance

A production artifact set must include everything required by the controlling contract. Where applicable, retain:

- exact question and input;
- UID and contract identity;
- implementation and orchestration identity;
- active reference, Manifold, metrology, and version identities with hashes;
- candidates and intermediate retained states;
- entropy, closure, and arbitration traces;
- terminal native result and exact terminal code;
- comparator-access record and empirical comparison;
- disposition and resolver output;
- complete transcript; and
- artifact manifest and cryptographic hashes.

The transcript and failure record are part of the scientific result. Do not remove an adverse result because it is inconvenient.

## Protect the current interaction authority

For native interaction work, the current executable authority is R28 followed by the R24 body and orbital continuation:

> independently resolved constituents → resolved pair state → Hamiltonian consequence → state-derived $K_{ab}$ → $H_{\mathrm{attr}}$ → pair response → finite-body aggregation → orbital continuation

Do not insert an independent `B_attr`, Newtonian $G$, a unit-amplitude surrogate, or a comparator-fitted coefficient into the native producer chain. Evidence 35 is the current pair-relation execution authority; Evidence 31 is the no-reduction body and orbital continuation authority. R166 audits one-law primitive identity but does not replace the R28-to-R24 execution chain.

## Write claims and public descriptions precisely

- Preserve the distinction between architecture, mechanism, classification, inference, and quantitative-with-comparator claims.
- State that completion is at the exact certified scope; do not imply that every possible application or empirical question has been exhausted.
- Do not call a symbolic or faceted resolved state unfinished merely because it is not a standalone scalar.
- Do not promote an empirical binding, downstream projection, or comparator relation to a native first-principles producer.
- In equations, $C$ denotes a candidate configuration; it is not a reference to the C programming language.
- Search metadata, FAQ schema, sitemaps, and IndexNow improve discovery mechanics but do not guarantee ranking, indexing, AI ingestion, citation, or scientific validation.

## Pull-request review gates

A reviewer should not approve a change until all applicable answers are **yes**:

1. Does the contribution identify its change class and controlling authority?
2. Does it preserve the complete retained state?
3. Are all changed inputs, methods, coefficients, tolerances, and boundaries explicit?
4. Does any changed execution have a new contract identity where required?
5. Was the native result frozen before comparator access?
6. Are terminal codes, adverse outcomes, transcripts, manifests, and hashes retained?
7. Are claim, evidence, closure, and standing records synchronized where affected?
8. Does the interaction chain preserve the R28-to-R24 authority and prohibited-substitution rules?
9. Do public statements remain within the certified scope?
10. Do tests or replays demonstrate the claimed effect without modifying unrelated results?

## Minimum contribution description

Every pull request should state:

- purpose and change class;
- controlling canonical files and sections;
- affected contracts, claims, certificates, and evidence records;
- exact files and artifacts changed;
- validation or replay commands and results;
- comparator-access status;
- terminal and disposition effects; and
- confirmation that unrelated certified results were not changed.

If an item does not apply, state why instead of omitting it.