# Source authority and claim boundary

## Contents

1. Operative source roles
2. Version and authority status
3. Paper-defined formalizations
4. Historical-evidence status
5. Claims that remain unsupported
6. Conflict handling

## 1. Operative source roles

Use the two bundled documents differently:

- `PARS_CANDIDATE_v1.25.0-candidate.6.md` is the primary operative reasoning specification. Apply its procedure to the user's task.
- `PARS_WHITEPAPER_PUBLIC_RELEASE_v1.0.pdf` and its extracted text explain the architecture, define an operational exact-binary research protocol, supply prompt locks and templates, document historical evidence, and state limitations.

Do not let explanatory language in the whitepaper silently promote the candidate specification or historical cases.

## 2. Version and authority status

Preserve these source-specific statements:

- Candidate.6 identifies candidate.5 as its immediate predecessor.
- Candidate.6 says candidate.5 remains failed/unpromoted.
- Candidate.6 identifies candidate.4 as the current passing candidate until prospective gates succeed.
- Candidate.6 labels itself a non-authoritative experimental repair candidate.
- Its purpose is to preserve candidate.5 recursive fan-out and verified adaptation while repairing a hard-constraint escape through unconditional pre-Build and mutation-sensitive post-Build invariant replay.
- The Control Integration subsection separately states that PARS v1.24.2 remains the authoritative parent for that experimental control layer.

Do not collapse these context-specific lineage statements into an invented single status. When a version claim matters, name the section/context and preserve the ambiguity. The safe global claim is that candidate.6 is experimental and unpromoted.

The whitepaper is Public Release v1.0. Its scope is the disclosed architecture, methods, documented artifacts, evaluation procedures, and historical evidence. Unpublished extensions, proprietary research directions, and non-public implementation plans are excluded.

## 3. Paper-defined formalizations

The whitepaper explicitly introduces several analytical or reporting terms rather than presenting them as verbatim named modules from candidate.6:

- Reasoning/Generation Plane, Materialization Plane, and Evidence Plane
- literal materializer as a paper-level operational definition
- PARS-FEBP
- Eleven Prompt Locks
- Classification-Over-Success Principle
- CCEBS
- F1-F10 prospective failure taxonomy
- PARS-ECS case-study reporting standard

Attribute these to the whitepaper when provenance matters. Do not claim they are established external standards.

## 4. Historical-evidence status

Treat the whitepaper's cases as Type C historical/development evidence unless prospectively regenerated under the frozen benchmark protocol. The selected cases illustrate methodological breadth, failures, repairs, evidence classes, and proof burden. They do not form a statistical sample of overall success.

Some original prompt archives were not recovered. Some verification occurred inside the same broader development environment as generation. The term "independent" in a retained record is not by itself proof of external third-party validation.

Report historical receipts as recorded claims. Do not retrospectively recertify upstream provenance without new evidence.

## 5. Claims that remain unsupported

Do not claim from these sources alone that:

- candidate.6 is promoted or authoritative;
- PARS prospectively outperforms simpler prompting;
- PARS improves general reasoning across domains;
- exact-byte generation generalizes to arbitrary programs or formats;
- a working or reconstructible binary establishes BP2;
- exact-byte generation reveals a unique internal cognitive mechanism;
- repair, context, memory, or controller edits establish model-parameter learning;
- historical cases are externally independently validated;
- public-domain status in one jurisdiction/date/version applies worldwide or to later additions;
- exact bytes are preferable to conventional software toolchains for normal engineering.

## 6. Conflict handling

When sources differ or use overlapping terms:

1. Preserve the user's explicit contract and higher-priority safety/policy requirements.
2. Use candidate.6 as the operative procedure.
3. Use the whitepaper for operational definitions, templates, historical context, and limitations.
4. Label paper-defined terms as paper-defined when attribution matters.
5. Preserve contradictory authority statements instead of resolving them by confidence.
6. Downgrade the claim or return inconclusive when the exact source boundary cannot be established.
