490d Repository Style Guide v2.5

Style Guide Version: v2.5 Revision date: August 28 2026 Prior version: v2.4 (June 9 2026 state, retained unaltered as the prior-version file) Canonical source: Markdown Status: Revised control file; v2.5 consolidated-workflow and control-architecture update under Repository Revision Plan v3.0; §2A and §27 rewritten from six sequential passes to the Unified Revision Pass with five editorial layers and a diff-based Verification Pass; §30 prompt template updated; per-file vocabulary (§31.38–§31.167, §32A–§32U, and File_36 / File_41 / File_45 glossary additions) migrated verbatim to State_Vocabulary_Register v1.0 with numbering preserved; historical Update Records and the v2.4 Revision Log Addendum migrated verbatim to Repository_Change_Archive v1.0; all editorial rules, terminology standards, number formatting, sign conventions, modal-state rules, Machine Guard formats, claim-status labels, Mirror protocols, and arithmetic controls retained unchanged; diff-audited June 10 2026; companion-control pointers refreshed to Register v1.3 / Procedures v3.1 / Capsule v11.4 / Archive v1.4 (June 10 2026, author-directed); companion-control pointers refreshed to Register v1.6 / Procedures v3.2 / Capsule v11.7 at File_40 integration (June 11 2026, author-directed one-line pointer update; the prior Active-companion line read Archive v1.3 against the June 10 status note of v1.4 — corrected to the last-attested v1.4, with the Archive's current location unconfirmed and under author review); companion-control pointers refreshed to Register v1.10 / Procedures v3.2 / Capsule v11.9 after File_50c integration (June 18 2026, author-directed one-line pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, or repository procedures changed); companion-control pointers refreshed to Register v1.11 / Procedures v3.2 / Capsule v11.10 after File_55 integration (June 20 2026, author-directed one-line pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, or repository procedures changed); companion-control pointers refreshed to Register v1.12 / Procedures v3.2 / Capsule v11.11 after the File_34 / File_55 hybrid Alulim clarification (June 21 2026, author-directed one-line pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, or repository procedures changed); companion-control pointers refreshed to Register v1.13 / Procedures v3.2 / Capsule v11.12 after the File_52a / File_52b post-final cross-file audit (June 26 2026, author-directed one-line pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, or repository procedures changed); companion-control pointers refreshed to Register v1.14 / Procedures v3.2 / Capsule v11.13 after the File_51a / File_55 public-clean control-registration update (June 27 2026, author-directed one-line pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, or repository procedures changed); companion-control pointers refreshed to Register v1.15 / Procedures v3.2 / Capsule v11.14 after the File_51b convention-entry update (June 27 2026, author-directed one-line pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, or repository procedures changed); companion-control pointers refreshed to Register v1.17 / Procedures v3.2 / Capsule v11.15 after the File_50a compact convention-entry update (June 27 2026, author-directed one-line pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, or repository procedures changed); companion-control pointers refreshed to Register v1.34 / Procedures v3.5 / Capsule v11.33 / Archive v1.43 after File_64 registration and File_63 full post-final pressure-test closure (July 26 2026, author-directed bounded pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, workflow rules, or repository procedures changed); companion-control pointers refreshed to Register v1.35 / Procedures v3.5 / Capsule v11.34 / Archive v1.43 after the expanded July 27 File_64 registration, reciprocal File_04 / File_08 / File_16 routing, and Restart Capsule v11.34 update (July 27 2026, author-directed bounded pointer update; no Style Guide rules, terminology standards, Machine Guards, claim-status labels, arithmetic controls, workflow rules, or repository procedures changed); full change history: Repository_Change_Archive; companion-control pointers refreshed to Register v1.36 / Procedures v3.5 / Capsule v11.35 / Archive v1.45 after File_65 Finalization, reciprocal File_08 / File_16 / File_29 / File_64 routing, and release-package preparation (August 3 2026, pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, or publication policy changed); companion-control pointers refreshed to Register v1.38 / Procedures v3.5 / Capsule v11.37 / Archive v1.47 / Manifest v19 after the File_66 August 5–7 amendment registration, reciprocal review, and coordinated release regeneration (August 8 2026, pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, or publication policy changed); companion-control pointers refreshed to Register v1.39 / Procedures v3.5 / Capsule v11.38 / Archive v1.48 / Manifest v20 after File_67 registration and coordinated release preparation (August 10 2026, pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, or publication policy changed); companion-control pointers refreshed to Register v1.40 / Procedures v3.5 / Capsule v11.39 after Final File_68 registration and eight reciprocal-source updates (August 13 2026, pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, or publication policy changed); companion-control pointers refreshed to Register v1.40 / Procedures v3.5 / Capsule v11.39 / Archive v1.49 / Manifest v21 after the coordinated File_67–File_68 release closure (August 15 2026, pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed); companion-control pointers refreshed to Register v1.41 / Procedures v3.5 / Capsule v11.40 / Archive v1.49 / Manifest v21 after Final File_69 control registration (August 17 2026, pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed; regular reciprocal-source and File_69 publication layers remain pending); companion-control pointers refreshed to Register v1.42 / Procedures v3.5 / Capsule v11.41 / Archive v1.51 / Manifest v23 after the August 18 Final File_69 thematic closure; pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed; companion-control pointers refreshed to Register v1.44 / Procedures v3.5 / Capsule v11.43 / Archive v1.52 / Manifest v24 after the August 21 File_69 Genesis Toledot–Shemot control registration and affected-only no-change reciprocal review; pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed; companion-control pointers refreshed to Register v1.45 / Procedures v3.5 / Capsule v11.44 after Final File_70 control registration, two reciprocal-source replacements, and index/landing/deployment-package preparation; Archive v1.52 and Manifest v24 retained pending author-supplied updates; pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed; companion-control pointers refreshed to Register v1.46 / Procedures v3.5 / Capsule v11.45 after the August 23 renewed Final File_70 Jacob burial-day / day–year guard registration and affected-only no-change reciprocal review; Archive v1.52 and Manifest v24 retained pending later author-directed update; pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed.; companion-control pointers refreshed to Register v1.48 / Procedures v3.5 / Capsule v11.47 after the August 25 nested Three-Gear correction, current File_70 full pressure test, all 19 remaining File_70 guard registrations, and affected-only no-change review; pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed; companion-control pointers refreshed to Register v1.49 / Procedures v3.5 / Capsule v11.48 after renewed Final File_70 trust-state alignment; pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed; companion-control pointers refreshed to Register v1.50 / Procedures v3.5 / Capsule v11.49 after renewed Final File_70 Supplement A central registration and current File_70 reciprocal-guard registration (August 27 2026, pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed); companion-control pointers refreshed to Register v1.51 / Procedures v3.5 / Capsule v11.50 after expanded Final File_70 Supplement A registration, affected-only review, and reciprocal File_70 routing (August 28 2026, pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed); companion-control pointers refreshed to Register v1.52 / Procedures v3.5 / Capsule v11.51 after the September 6 2026 Sothic/365-day companion and File_18 Lamech-188 central registration; pointer-only maintenance; no Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed Active companion controls: State_Vocabulary_Register v1.54; Project_Procedures v3.5; Restart Capsule v11.53; Repository_Change_Archive v1.52 (non-controlling prior history); Publication Manifest v24 (prior release manifest); current Final File_70; September 6 verification-complete bounded File_12, File_22, and File_70 Supplement A amendments; September 8 Lamech source-hierarchy clarification registered at §D.43; bounded File_00/17/46/51a routing

Derived from Files 51, 53, 54, File_00 final pressure-tested conventions, File_02 final pressure-tested Flood/SKL conventions, File_03 final File-map convention, the Repository Conformity Plan, File_21 final post-final pressure-tested controls, File_22 final post-final pressure-tested controls, File_25 final post-final pressure-tested Decimal Invariance controls, File_34 final post-final pressure-tested SKL / Berossus controls, and the machine-ingestion / state-safe retrieval refinement — May 2026

This guide defines the canonical repository standard going forward. It is based primarily on the final revised form of File 51, with additional implementation controls drawn from the repository-wide conformity plan. The purpose is not merely cosmetic standardization. The purpose is to convert the repository into a consistent, AI-forward Markdown source system that preserves arithmetic precision, modal-state logic, theological restraint, and cross-file retrievability.

This guide governs the source text. WordPress, HTML, PDF, and DOCX versions are derived publication layers.

The operative editorial rule remains:

clarify the logic, preserve the terminology, reduce compression, add no ornament.

More specifically:

when a paragraph moves between modal systems, chronological traditions, node-classes, arithmetic operators, or mirror protocols, restate the active state explicitly; do not rely on implied carryover.

0. Scope and Rule Types

0.1 Derived rules

Derived rules are rules clearly evidenced in File 51 itself, especially in its handling of:

• modal states;
• node-classes;
• sign conventions;
• cross-axis arithmetic;
• exact half-year states;
• table framing;
• terminology discipline;
• source-text restraint.

0.2 House rules

House rules are added for repository-wide normalization in Markdown, even where File 51 implies the practice but does not formalize it. Examples include:

• Markdown as canonical source format;
• restrained Markdown syntax;
• explicit source/publication separation;
• file-level metadata blocks;
• claim-status labels;
• revision pass types;
• audit-note discipline;
• repository-wide dependency tracking.

0.3 Implementation rules

Implementation rules govern the process of revising older repository files into the current standard. These rules are procedural rather than stylistic. They define how each file should be audited, revised, risk-rated, and prepared for derived publication.

0.4 Editorial aim

The repository standard is:

• exact;
• spare;
• state-tagged where needed;
• human-readable;
• AI-forward;
• free of rhetorical inflation;
• structurally stable across future revision passes.

Precision outranks smoothness. If a sentence is difficult but precise, do not simplify it unless the underlying meaning is understood.

1. Canonical Source Format

1.1 Repository master format

All repository files should be maintained first in Markdown.

Markdown is the canonical source because it is:

• plain text;
• structurally explicit;
• easy to diff, search, chunk, and standardize;
• easy to convert later into publication formats;
• better suited for AI retrieval than visually formatted publication layers.

1.2 Markdown standard

Use restrained Markdown:

• headings with #, ##, ###, and ####;
• plain paragraphs;
• plain Markdown tables;
• LaTeX math with $...$ and $$...$$;
• no raw HTML unless absolutely necessary;
• no decorative formatting.

1.3 Source vs publication

The repository follows this model:

Once Markdown normalization begins, WordPress should not be treated as the primary editing environment.

1.4 Conversion principle

Derived publication formats must preserve the Markdown source structure as closely as possible. Conversion must not silently rewrite terminology, arithmetic notation, state-language, section numbering, table framing, or claim-status labels.

1A. Standard File Header

1A.1 Required header fields

Each repository file should begin with a compact Markdown header block before the main title.

Required fields:

File:
Title:
Status:
Primary domain:
Canonical source:
Revision basis:

Optional fields where useful:

Traditions:
Primary anchors:
Related files:
Major operators:
Major modal states:

Recommended full form:

File: File_53
Title: The Book of Jubilees as a 22-Fold Creation-Genealogy Witness
Status: Draft / Revised / Final
Primary domain: Comparative; Theological
Traditions: BJ; MT; SP; LXX
Canonical source: Markdown
Primary anchors: 3856 BC; 1406 BC; 1399 BC
Related files: File_51c; File_52a
Major operators: 25/23; 70/69; 300/299
Major modal states: Cainan expunged; restored 2nd Cainan; +30 Apparent Age
Revision basis: 490d Repository Style Guide v2.4

1A.2 Function of the header

The file header is informational. It must not replace the H1 title or numbered sections.

The header helps future AI retrieval by identifying:

• file identity;
• file status;
• active chronological domain;
• primary anchors;
• related files;
• major operators;
• major modal states;
• revision basis.

1A.3 Status field

Use one of the following status labels unless a local project requires a more specific label:

1A.4 Primary domain and traditions

Use Primary domain for the file’s main analytical domain.

Preferred domain labels:

• Regular;
• Cumulative;
• Rounded;
• Mirror;
• Prime;
• Comparative;
• Calendar;
• Statistical;
• Theological;
• Methodological.

Use Traditions when the file specifically involves textual, chronological, or extra-biblical traditions.

Preferred tradition labels:

• MT;
• SP;
• LXX;
• BJ;
• SOR;
• SKL;
• Berossus.

Example:

Primary domain: Comparative; Cumulative
Traditions: MT; SP; LXX; BJ

1B. File Map

1B.1 Purpose

A File map is a terse functional index placed near the top of a repository file when it improves AI retrieval.

It answers this question:

Where is the relevant logic located in this file?

A File map should identify section function. Where useful, it may also identify active state, operator, node-class, or dependency status.

1B.2 Placement

Preferred placement:

## 0. File-function
## 0.1 Working state register
## 0.2 File map

If the file does not use a working state register, place the File map immediately after ## 0. File-function.

The File map should appear before the first dense argumentative or arithmetic section.

1B.3 Standard form

Preferred form for complex files:

## 0.2 File map

| Section | Function | Active state / operator |
|---|---|---|
| §0 | File-function and state controls | file-level modal states |
| §1 | Main identity or thesis | active tradition/state |
| §2 | Core arithmetic or logic engine | stated operators |
| §3 | Verification or synthesis | arithmetic facts / structural inference |
| §4 | Cross-references and dependencies | dependency tracking |

Preferred form for short files:

## 0.2 File map

| Section | Function |
|---|---|
| §0 | Defines file function and active states |
| §1 | Identifies the main figure, thesis, or file subject |
| §2 | Records the primary logic engine or harmonic anchors |
| §3 | Verifies stated dates and spans |
| §4 | Lists cross-file dependencies |

1B.4 Restraint rule

A File map is not a decorative table of contents.

Do not use it to:

• repeat every heading mechanically;
• summarize the file in prose;
• add rhetorical framing;
• replace the file header;
• replace the modal-state register;
• replace the cross-reference index.

Use it only when it improves retrieval, navigation, or state/operator recognition.

1B.5 AI-forward rule

The File map should be functional rather than literary.

Good File map entries use labels such as:

• file-function;
• state controls;
• logic engine;
• arithmetic verification;
• claim-status control;
• cross-file dependencies;
• appendix-only material.

Avoid vague entries such as:

• Introduction;
• Background;
• Discussion;
• Conclusion;

unless the local file actually uses those headings and their function is already clear.

1C. Machine-Ingestion and Derived AI Formats

1C.1 Canonical-source rule

The canonical repository source remains Markdown.

RAG indexes, Knowledge Graph records, JSON exports, JSONL fine-tuning datasets, prompt/response pairs, embedding metadata, and similar AI-facing formats are derived extraction layers.

Do not distort the Markdown source in order to imitate a future training dataset. The source file should remain a state-controlled repository file, not a synthetic dialogue transcript.

1C.2 State-safe retrieval

The repository is optimized for state-safe retrieval.

State-safe retrieval means that an AI system should be able to retrieve a paragraph, table, File map entry, Machine Guard, or appendix note without losing the governing state.

Where needed, a retrieved chunk should carry or sit near enough to identify:

• active state;
• chronological tradition;
• node-class;
• operator;
• claim-status;
• dependency source;
• main-body, appendix-only, Mirror, inverse, statistical, or exploratory status.

The chief ingestion risk is not merely poor retrieval. The chief risk is correct retrieval applied under the wrong state, operator, tradition, node-class, or claim-status.

1C.3 Metadata and extraction discipline

Stable headers, File maps, state registers, claim-status notes, and Machine Guards make the Markdown source extractable. They should be written for source clarity first and machine extraction second.

Do not require every file to carry unused optional metadata fields. Required header fields remain required. Optional fields should be included only when they improve retrieval, indexing, dependency recognition, or state recognition.

1C.4 JSON / JSONL derivation

If JSON, JSONL, Knowledge Graph triples, vector-index metadata, or prompt/response training pairs are produced later, they should be generated from the canonical Markdown source.

A later extraction script may map:

This extraction should preserve source meaning. It must not silently rewrite arithmetic, anchors, modal states, node-classes, sign conventions, operators, Mirror protocols, inverse-number status, claim-status labels, or dependency boundaries.

Machine Guard [CANONICAL MARKDOWN / DERIVED AI FORMATS]: Markdown is the canonical repository source. RAG indexes, Knowledge Graph records, JSON, JSONL, embedding metadata, and prompt/response training datasets are derived extraction layers. Do not reshape the source file into dialogue format, training-pair format, or generic AI-summary format if doing so weakens arithmetic precision, modal-state control, operator clarity, node-class distinction, claim-status control, or dependency boundaries.

2. Core Editorial Principles

2.1 No rhetorical inflation

State arithmetic facts directly. Do not intensify them rhetorically.

Avoid phrases such as:

• proves beyond doubt;
• astonishing;
• incredible;
• undeniable;
• clearly designed, unless the file truly establishes that level of claim.

Let arithmetic, factorization, recurrence, textual anchoring, and state-control carry the force of the argument.

2.2 Arithmetic facts vs interpretive statements

Arithmetic facts should be stated directly.

Structural inferences should use measured language such as:

• suggests;
• is consistent with;
• appears to;
• is compatible with;
• supports the possibility that;
• functions as corroboration for.

Statistical results should be described as:

• occurs more frequently than expected;
• exceeds the baseline expectation;
• is statistically notable under the stated test.

Statistical results should not be described as proving authorial intent by themselves.

2.3 Theological restraint

Standard, non-controversial theological observations within the biblical and Christian tradition may be stated directly when they are not the sole support for a mathematical or structural claim.

More specialized, disputed, or structurally load-bearing theological interpretations should use measured language.

2.3a Theological and typological note preservation

Theological, typological, and symbolic observations should not be deleted merely because they are not mathematical. The repository’s numerical arguments often require theological framing in order to explain why a number, span, node, or recurrence matters.

The rule is therefore not removal, but classification.

When theological material is:

• textually anchored;
• necessary to explain the meaning of a numeric structure;
• coherent with the file’s active biblical or extra-biblical source;
• not being used to replace arithmetic proof;

it should be preserved as a labeled note, aside, or subsection.

Preferred labels:

• Theological note:
• Typological note:
• Symbolic note:
• Canonical note:
• Reception-history note:

Use these notes to preserve theological meaning while preventing the theological claim from silently carrying the arithmetic burden.

Correct:

```markdown
Typological note:
The 22 × 490 structure visually resonates with Revelation's Alpha-Omega, First/Last, and Beginning/End language. This note explains the theological fit, but the arithmetic basis remains the outer Luke rail span and the overlapped middle generation. Additional source backgrounds require local source-control if opened.
```

2.4 Do not revise what is not understood

If a sentence is difficult but precise, do not simplify it unless the underlying meaning is clear.

If a value appears inconsistent, do not silently correct it. Mark it with an audit note.

2.5 Compression vs clarity

The repository may use dense technical prose. The aim is not to make every file elementary. The aim is to make each file explicit enough that a competent human reader and an advanced AI system can identify:

• active state;
• node-class;
• arithmetic operator;
• chronological tradition;
• claim-status;
• dependency structure.

2A. Editorial Layers and the Consolidated Workflow

2A.0 Workflow form

Under Project Procedures v3.0, repository normalization proceeds in three turns per file, not six sequential passes:

1. Pass 0 — Intake + Mechanical Lint: File Intake Sheet, risk rating, deterministic lint report, section-level revision plan. No revision occurs.
2. Pass 1 — Unified Revision Pass: one controlled rewrite applying all five editorial layers below, section by section, under all content invariants.
3. Pass 2 — Verification Pass: machine diff between source and revision; audit of every change by class; scripted arithmetic recheck where parseable; consolidated Author-Decision list.

Finalization remains a separate author-invoked act. High-risk files split Pass 1 once (layers 1–3, then layers 4–5). The five layers below are no longer separate passes; they are the checklists the Unified Revision Pass must satisfy simultaneously, and the audit classes the Verification Pass confirms.

2A.1 Structural layer

Correct heading hierarchy, section numbering, appendix placement, table framing, file-map placement, and Markdown source structure.

When a File map improves AI retrieval, add it. Keep it terse, functional, and state-aware. Do not use it as a decorative table of contents. Complete the machine-ingestion check where applicable.

Checklist:

Structural layer satisfied:
- headings normalized
- section hierarchy corrected
- appendices nested correctly
- tables identified
- file header added
- File map added or confirmed unnecessary
- machine-ingestion check completed where applicable

2A.2 Terminology layer

Normalize repository terms, capitalization, hyphenation, node-class language, modal-state labels, and cross-file references.

Checklist:

Terminology layer satisfied:
- number formatting normalized
- BC/AD formatting normalized
- repository terms capitalized
- technical compounds normalized
- local file-reference style preserved

2A.3 Modal-State layer

Audit modal states, node-classes, sign conventions, slash-pairs, ranges, display labels, and mirror protocols.

Checklist:

Modal-State layer satisfied:
- modal states preserved
- node-classes tagged
- sign conventions defined
- slash-pairs/ranges clarified
- no display label substituted for computational state

2A.4 Arithmetic layer

Verify same-side spans, cross-axis spans, exact ratios, date ranges, half-year states, Key-of-23 conversions, and undefined operator dependencies.

Checklist:

Arithmetic layer satisfied:
- same-side spans checked
- cross-axis spans checked
- Key conversions checked
- exact halves preserved
- undefined dependencies flagged
- no computational rounding introduced

2A.5 Argument layer

Reduce rhetorical inflation, clarify claim-status, distinguish arithmetic facts from interpretive statements, and add state-tags where dense argumentation shifts systems.

Checklist:

Argument layer satisfied:
- rhetorical inflation reduced
- claim status clarified
- weak material moved or labeled
- tables framed
- dense paragraphs decompressed without diluting precision

2A.6 Publication Pass

The Publication Pass remains a separate, later step. Prepare the conformed Markdown for WordPress or other derived publication formats without altering source terminology, arithmetic, or state-language.

Deliverable:

Publication Pass Complete:
- Markdown source preserved
- publication formatting applied only at derived layer
- section numbers preserved
- tables preserved or safely converted
- no source terminology altered

Machine Guard [UNIFIED PASS INVARIANTS]: Consolidating the layers into one pass does not relax any content invariant. Do not silently correct arithmetic. Do not alter anchors, modal states, node-classes, sign conventions, operators, Mirror protocols, or theological claims. Audit-note and dependency-note discipline, authorial-direction thresholds, and all namespace, firewall, and non-retrojection controls apply within the Unified Revision Pass exactly as they applied across the former sequential passes.

2B. Claim-Status Labels

2B.1 Purpose

When a file contains layered argumentation, use explicit claim-status language. This prevents the collapse of textual data, arithmetic facts, structural inference, authorial design, providential synchronization, and exploratory observation into one undifferentiated claim.

2B.2 Preferred labels

2B.3 Primary burden rule

Do not allow providential, exploratory, statistical, or appendix-only material to carry the primary burden of proof unless the file explicitly announces that such material is the subject of investigation.

2B.4 Authorial vs providential distinction

When a pattern plausibly exceeds what can be attributed to an ancient author or tradition, label it as providential synchronization or structural overpattern rather than probable authorial design.

Correct:

As an arithmetic fact, the span equals 2450. As a structural inference, this supports the claim that the BJ framework is built around a jubilee architecture. The later Mirror recurrence is better treated as providential synchronization or secondary corroboration, not as direct evidence of BJ authorial intent.

Incorrect:

The Mirror recurrence proves that the author of Jubilees intended the later AD alignment.

2B.5 Restraint rule

Claim-status labels should be used where they clarify layered argumentation. They do not need to be attached to every sentence or every arithmetic fact.

Use explicit labels when:

• authorial intent and providential synchronization might be confused;
• appendix-only material might be mistaken for the primary argument;
• statistical or exploratory material appears near the main thesis;
• a file moves between textual datum, arithmetic fact, and structural inference.

Do not overload ordinary prose with unnecessary claim-status labels.

3. Heading Hierarchy

Use strict hierarchical nesting. Do not skip levels.

3.1 General rules

• A subsection must sit under its parent section.
• Bold text must not substitute for a heading.
• If content needs a section number, it needs a heading.
• Appendix sections such as A.1 and A.2 use H3 under an H2 appendix header.
• Do not use heading levels decoratively.

3.2 Alphanumeric branches

Lettered branches are valid and must still nest properly.

Examples:

• 4A;
• 4A.1;
• 7A;
• 14.1a;
• 14.8.1;
• A.1.

3.3 One H1 rule

Each file should have one H1 title only. The file header may precede the H1 title, but it is not itself the title.

3.4 Appendix heading rule

Use appendices for material that is secondary to the main argument.

Preferred form:

## Appendix A. Mirror Stress-Test Material

### A.1 First appendix subsection

4. Number Formatting

4.1 No commas in numbers

All numbers appear without commas.

Correct:

• 14006 BC;
• 12600;
• 258600;
• 100000 iterations.

Incorrect:

• 14006 BC;
• 12600;
• 258600;
• 100000 iterations.

This applies in:

• prose;
• tables;
• math;
• notes;
• captions;
• file headers;
• appendix material.

4.2 BC/AD formatting

Use:

• 4106 BC;
• AD 4105.

Do not use:

• 4106BC;
• 4106 B.C.;
• 4106 BC;
• 4105 AD.

A-space values carry no BC/AD suffix:

• A = −4105.

4.3 Ranges and spans

Use an en-dash for ranges:

• 4121–4114 BC;
• 4121.5–4114.5 BC.

Use to in prose:

• from 4106 BC to 1406 BC.

Use = for span results:

• 4106 − 1406 = 2700.

4.4 Exact halves

Half-year values are permitted only as exact .5 values.

Examples:

• 2518.5 BC;
• 4121.5–4114.5 BC.

Do not introduce arbitrary decimal expansions. Only integers, exact halves, and exact rational expressions belong in the source unless a specific exact rational is intended.

4.5 Exact rationals

Exact rational expressions may be used where the repository system requires them.

Examples:

• 25/23;
• 70/69;
• 300/299;
• 23/40.

Do not replace exact rationals with rounded decimal approximations unless a derived explanatory note explicitly requires it.

4.6 Key-of-23 Residue Protocol

The normal Key-of-23 operators remain exact whole-year conversion ratios:

• 25/23;
• 70/69;
• 300/299.

The Residue Protocol is a separate drift-to-day register. It is invoked only when a file explicitly shifts from ordinary whole-year Key-of-23 conversion to physical residue or conceptual residual-display.

When the Residue Protocol is active, use these working definitions:

K = schematic Key-of-23 solar-equivalent year
S_K = calibrated solar year used by the Residue Protocol
R_23 = root physical residue per 23 solar years

The shared schematic year is:

K = (25 × 336) / 23
K = (70 × 360) / 69
K = (300 × 364) / 299
K = 8400 / 23 = 365.217391304... days

The calibrated solar year used by the protocol is represented in exact working form as:

R_23 = 23/40 day = 0.575 day
S_K = K + 1/40
S_K = 8400/23 + 1/40
S_K = 336023/920 = 365.242391304... days

Display rule: The decimal 365.2423914 is a rounded display of S_K. Use 336023/920 where exact residue arithmetic is required.

The root block is:

23 × S_K = 8400 + 23/40
23 × S_K = 8400.575 days
23S_K − 8400 = 23/40 = 0.575 day

General physical-residue formula:

Residue over N solar years = N × (S_K − K)
Residue over N solar years = N / 40 days

For a Key-of-23 ratio p/q, where p is the schematic-calendar side and q is the calibrated solar-year side:

Physical residue over q solar years = q/40 days
Conceptual residual-display = (q/40) × p/q = p/40 days

Compact register:

Machine Guard [RESIDUE PROTOCOL]: The residue formula does not replace ordinary Key-of-23 whole-number conversion. Use 25/23, 70/69, and 300/299 as exact rational operators for chronological conversion. Invoke residue arithmetic only where the file explicitly shifts from whole-year conversion to drift-to-day calculation. Distinguish physical residue from conceptual residual-display. Do not feed display constants such as 0.625, 1.75, 7.0, 7.5, or 175 back into ordinary date arithmetic as if they were civil-year spans. When 6.9 days is displayed as 7.0 days, the operation is residual day-year lift: 6.9 years × 70/69 = 7 years, with 7 schematic years corresponding to 2520 days. It is not a physical residue-rounding rule.

4.7 Conceptual residual-display and residual day-year lift

Physical residue and conceptual residual-display are distinct node-classes.

The conceptual residual-display is not ordinary rounding. It is a day-year echo. Residue-days may echo the corresponding residue-years; therefore the same Key-of-23 operator may lift the display value even though the physical residue remains unchanged.

Example:

276 / 40 = 6.9 physical residue-days
6.9 years × 70/69 = 7 years
7 × 360 = 2520 days

Therefore:

6.9 physical residue-days → 7.0 conceptual residual-display days

The 175-day display follows the same rule:

25 × 276 = 6900 years
6900 / 40 = 172.5 physical residue-days
25 × 7.0 residual-display days = 175 residual-display days

Do not treat 175 as the physical residue over 6900 years unless the file explicitly defines a local operator that changes the active state from physical residue to residual day-year display.

5. Span Arithmetic

5.1 Same-side spans

When both dates lie on the same side of the BC/AD axis, compute by subtraction.

Examples:

• 4106 − 1406 = 2700;
• 3486 − 1886 = 1600.

5.2 Cross-axis spans

When the span crosses the BC/AD axis, use the repository-standard formula:

BC + AD − 1

Example:

4166 + 4115 − 1 = 8280

5.3 Do not mix operators

Do not apply same-side subtraction to cross-axis spans. Do not apply BC + AD − 1 to same-side spans.

5.4 Civil-year note

The repository uses civil BC/AD reckoning with no year 0. This is why cross-axis spans use BC + AD − 1.

5.5 Audit categories for arithmetic

Every Arithmetic-layer check (within the Unified Revision Pass, or as a standalone Arithmetic Pass under the High-risk split) should cover at least these categories:

6. Terminology Standards

6.1 Capitalized system terms

Capitalize the following when used as repository terms:

• Actual MT;
• Rounded Scaffold;
• Creation;
• Flood;
• Conquest;
• Exodus;
• Entry when functioning as the Egypt-entry node;
• Exile / Captivity when functioning as fixed chronological nodes;
• Key of 23;
• Residue Protocol when functioning as the named Key-of-23 drift-to-day register;
• +30 Apparent Age;
• +60 Terah;
• 2nd Cainan when functioning as a recognized variant-state label;
• Book of Jubilees;
• BJ when used as the repository abbreviation;
• SKL when used as the repository abbreviation for Sumerian King List;
• Berossus;
• MT Minimum-Regular;
• MT Standard-Normal;
• Sumerian A / SKL Short;
• Sumerian B / SKL Long;
• +30 Apparent Mode;
• +2 local rail when used as a formal SKL rail label;
• +720 scale-state when used as a formal SKL/Berossus scale label;
• Flood Week when used as a formal cumulative envelope label;
• Mirror when functioning as a named repository structure.

6.2 Lowercase technical terms

Prefer lowercase in prose for generic technical descriptors:

• mod-5;
• mod-30;
• cross-tradition;
• cycle-family;
• node-class;
• cross-modal;
• boundary-state;
• phase-resolved;
• rounded-to-rounded;
• same-side;
• cross-axis.

Capitalize these only at sentence start, in titles, or when part of a formal label.

6.3 Preferred terminology

Use:

• actual rather than original for unrounded MT states;
• cross-tradition for MT/LXX/SP comparative language;
• patriarch for ordinal sequence counting, as in 23rd patriarch;
• chronological tradition for MT/SP/LXX/BJ/SOR-type systems;
• state for valid modal alternatives;
• operator for a defined mathematical procedure;
• anchor only when the date functions as an anchoring node.

6.4 Narrow rule on generation

Do not ban the word generation absolutely.

Use:

• patriarch for ordinal count;
• generation where the biblical generational concept is actually intended.

Correct distinction:

• Joseph is the 23rd patriarch from Adam;
• Four generations of 110.

6.5 Avoid vague substitutions

Do not replace precise repository terms with smoother but less exact synonyms.

Examples:

6.6 Cainan / Kainan spelling

Use 2nd Cainan as the default repository variant-state label unless a file has adopted a local spelling convention.

Use Kainan when:

• quoting or closely following a translation that uses Kainan;
• discussing BJ-specific narrative material where the file has explicitly adopted that spelling;
• preserving the author’s local terminology.

Use Cainan expunged and restored 2nd Cainan as standard state labels unless the local file defines otherwise.

If both spellings appear in one file, define the convention on first use.

6.7 File_02 Flood and SKL terminology

The following terms are repository-wide labels after the File_02 Flood/SKL update.

Avoid bare MT Regular when the file requires the distinction between MT Minimum-Regular and MT Standard-Normal. Avoid bare Sumerian A or Sumerian B without defining whether the active label means SKL Short or SKL Long.

7. Hyphenation Rules

Technical compounds are normally hyphenated when used adjectivally.

Examples:

• pre-Flood;
• post-Flood;
• cross-axis;
• boundary-state;
• phase-resolved;
• rounded-to-rounded;
• same-side;
• cross-modal;
• node-class;
• cycle-family;
• Creation-week;
• source-text;
• file-level;
• cross-file;
• state-tagged;
• AI-forward.

7.1 Creation-week

Use Creation-week as the standard adjectival compound.

Do not vary it as:

• Creation week;
• creation-week;
• Creation Week;

unless grammar strictly requires another form.

7.2 Mod compounds

Use:

• mod-5;
• mod-30;
• mod-210.

Do not use:

• mod 5;
• mod5;
• Mod-5, unless at sentence start or in a formal title.

8. Sign Conventions

8.1 Sign conventions are local, not global

A file may contain more than one valid sign convention. When a convention changes, it must be explicitly defined at the point of use.

Examples:

• Scaffold → Actual MT;
• Shift = Rounded BC − Actual BC.

Do not assume one implicit convention for the whole file.

8.2 Standard phrasing

When adjustments are described, use direct notation such as:

• Scaffold → Actual MT;
• Rounded + Adjustment = Actual MT;
• 4(+2) + 2(−1) = +6.

If a sign rule reverses in a later table, say so explicitly.

8.3 Sign convention table framing

Any table with a non-obvious sign convention must include a short framing note immediately before the table.

Example:

The following table uses `Shift = Rounded BC − Actual BC`. Positive values therefore indicate that the rounded state is earlier than the actual state in BC reckoning.

9. Modal States and Node-Classes

This is one of the central repository standards.

9.1 Preserve modal states

When two or more valid chronological states coexist, preserve them as states. Do not collapse them into one correct value unless the file explicitly requires that.

Use language such as:

• simultaneous, non-competing modal states;
• must not overwrite;
• preserve as modal states per domain;
• do not reconcile;
• working state in this file;
• alternate local option.

Avoid language such as:

• the correct date is;
• this replaces;
• this supersedes;

unless replacement is genuinely intended.

9.2 Distinguish node-classes

Do not collapse different node-classes merely because their numerical values are related.

Examples of distinct node-classes:

• endpoint;
• anchor;
• boundary;
• block;
• envelope;
• spread;
• mirror target;
• modal overlap node;
• comparison state;
• hinge;
• bridge;
• trunk;
• branch;
• pillar;
• register;
• control node.

A file should identify the node-class clearly on first use when confusion is possible.

9.3 State-tag persistence

In dense paragraphs, restate the active state whenever the text shifts system, layer, or node-class.

Examples of shifts requiring renewed tagging:

• rounded → actual;
• regular → cumulative;
• base → +60;
• base → +30;
• MT → SP → LXX;
• transmitted SP → alternate SP;
• Year-6 anchor → comparison state;
• boundary → endpoint;
• same-side arithmetic → cross-axis arithmetic;
• authorial claim → providential synchronization.

Do not rely on implied carryover in dense argumentation.

9.4 New subsection rule

Do not assume state continuity across subsection boundaries. On first use in a new dense subsection, restate the relevant state, node-class, or sign convention.

9.5 Modal-state table

When several modal states are active, a compact table is preferred.

Example:

9.6 Minimum-Regular and Standard-Normal states

Some files require two simultaneous uses of regular MT terminology. The File_02 standard is:

Machine Guard [MT MINIMUM / STANDARD-NORMAL]: Do not collapse MT Minimum-Regular and MT Standard-Normal into bare MT Regular. The minimum state may be the forward-most comparison position, while the standard-normal state may be the normative operating date. Identify which state is active before computing.

9.7 SKL Short / Long and scale-state rails

When a file uses the Sumerian King List as a chronological witness, preserve the SKL state and rail.

Rail labels:

Machine Guard [SKL +2 / +720 SCALE-STATE]: The SKL +2 local rail and the SKL/Berossus +720 scale-state are related scale states, not interchangeable arithmetic operators. Apply +2 directly only when the local SKL beginning-and-anchor pair is active. Declare the +720 or ±720 scale-state explicitly when operating in the cosmic SKL/Berossus grid.

9.8 Rounded Scaffold methodological status

The Rounded Scaffold is a methodological and geometric deduction built on the back of the actual chronologies. It is not a literal chronology of MT, SP, LXX, BJ, SOR, SKL, or Berossus.

Before File_51a or another file that explicitly opens the Rounded Scaffold, references to Rounded Scaffold values should be clarity-only forward references. They may distinguish a rounded methodological state from normal chronological states, but they must not make the Rounded Scaffold carry the literal chronological argument.

Example:

Machine Guard [ROUNDED SCAFFOLD STATUS]: The Rounded Scaffold is a methodological deduction and comparison layer, not a literal chronology of MT, SP, LXX, BJ, SOR, SKL, or Berossus. Before File_51a opens the Rounded Scaffold directly, cite Rounded Scaffold values only to prevent state confusion. Do not let rounded values overwrite actual, standard, BJ, SOR, or tradition-specific chronology.

9.8a Rounded Scaffold non-retrojection

The Rounded Scaffold / rounded root chronology is the File_51a methodological mod-5 layer. It must not be retrojected into earlier repository files or into ordinary actual chronology states unless a local section explicitly opens the File_51a Rounded Scaffold state.

Default rule: Regular chronology, cumulative chronology, comparative textual chronology, SKL chronology, Mirror displays, calendar states, prophetic span displays, and local 10x scale-states remain actual / local-state chronologies unless the local file explicitly opens the Rounded Scaffold state.

Clean values, mod-10 displays, 10x scale-states, Mirror displays, SKL mod-10 displays, harmonically regular values, or apparently rounded values are not thereby File_51a Rounded Scaffold values. A clean number is not automatically a rounded number.

File_22 control example: The 9890 cumulative-to-regular MT Creation bridge is actual chronology in File_22. The File_51a rounded counterpart is 9900, a separate rounded chronology state. The two values may be compared, but one must not replace the other.

Machine Guard [ROUNDED SCAFFOLD NON-RETROJECTION]: Do not identify clean, mod-10, harmonically regular, Mirror, SKL mod-10, 10x-scaled, or apparently rounded values with the File_51a Rounded Scaffold unless the local section explicitly opens that state. File_22's 9890 Cumulative-Regular Decimal Bridge is actual chronology. The 9900 rounded counterpart belongs to the later Rounded Scaffold state.

10. Exact States vs Display Labels

10.1 Computational state vs display label

When a half-year or phase-resolved value exists, preserve the exact computational state internally and distinguish it from its display label.

Example:

• computational state: 2518.5 BC;
• display label: Tishri 2519 BC.

10.2 Rule

Exact states govern arithmetic. Display labels govern presentation.

10.3 Safeguard

Display labels must not be fed back into computation as replacement states.

10.4 Phase-resolved caution

If a date is phase-resolved, identify whether the file is using:

• Tishri reckoning;
• Nisan reckoning;
• midpoint-pivot logic;
• display-only labels;
• exact computational values.

10.5 Calendar-state suffixes: n and t

The suffixes n and t are calendar-state display labels. They are part of the modal state and must not be removed during arithmetic verification.

Standard meanings:

Examples:

• 2460n BC;
• 1959t–1955n BC;
• AD 1952t–1955n.

Nisan remains the default state when no suffix appears, unless the local file explicitly defines a different default. Tishri remains valid where stated.

A suffixed date is not automatically an exact .5 computational state. Exact half-year values govern arithmetic only when the file states an exact .5 value or defines a phase-resolved computation. Otherwise, n and t remain display labels and modal-state identifiers.

Machine Guard [CALENDAR SUFFIXES]: Do not strip n or t from a date label during revision. Do not convert n or t into .5 arithmetic unless the file explicitly defines the exact phase-resolved value. Treat suffixed dates as calendar-state display labels until a local operator converts them into computational states.

11. Slash-Pairs, Ranges, Blocks, and Envelopes

These forms are not interchangeable.

11.1 Slash-pairs

Use slash-pairs for paired states such as:

• 4416/4411 BC;
• 1406/1401 BC.

A slash-pair is not an ordinary alternative. It usually represents an ordered pair of block-members, boundary states, or parallel endpoints.

11.2 Order matters

Do not reverse a slash-pair casually. If the pair represents upper/lower, earlier/later, or two fixed boundary members, preserve the ordering.

11.3 En-dash ranges

Use en-dash ranges for continuous spans or envelopes such as:

• 4121–4114 BC;
• 4121.5–4114.5 BC.

11.4 Block language

If a slash-pair functions as a named block, say so explicitly:

• SP rounded Creation block: 4416/4411 BC.

11.5 Envelope language

If a range functions as an actual or phase-resolved envelope, say so explicitly:

• actual base Creation-week envelope: 4121–4114 BC;
• spread envelope: 4121.5–4114.5 BC.

11.6 Slash-pair audit rule

When revising a slash-pair, check:

• whether the order is meaningful;
• whether both members are active;
• whether one member is upper/lower;
• whether one member is transmitted/alternate;
• whether the pair is a block, boundary pair, or comparison pair.

11.7 Full slash-pair display for compressed source forms

Compressed slash-pair shorthand is error-prone for AI parsing. When revising older files, expand compressed slash-pair forms into full endpoint display unless the local file explicitly requires the compressed form as a source-history label.

Example:

Source shorthand: 13997/6 BC
Preferred revised display: 13997/13996 BC

The full display preserves both members of the pair and prevents the second member from being misread as 6 BC, as a range endpoint, or as a typographical remnant.

11.8 Slash-pair plus Mirror target safety

When a slash-pair is paired with an AD Mirror target, do not automatically treat the slash-pair as an executable civil-span endpoint.

Required classification:

If the file asserts a civil cross-axis span from a slash-pair to an AD date, check each member component-wise with BC + AD − 1.

Example:

13997 + 14000 − 1 = 27996
13996 + 14000 − 1 = 27995

If the claimed span does not follow from the component-wise civil calculation, do not introduce a second missing-year operator. Add an Audit note: or classify the expression as a Mirror display / adjusted state until the governing target-generation protocol is supplied.

Machine Guard [SLASH-PAIR SAFETY]: A slash-pair is not a range, average, or loose alternative. When paired with a Mirror target, identify the node-class before computing. Civil spans still use BC + AD − 1; Mirror target generation, A-space display, and adjusted cumulative display are separate protocols.

11.9 Flood Weeks and judgment-week envelopes

A cumulative Flood Week is an envelope, not a single-year anchor and not an inclusive ordinal count unless the local file explicitly defines such a count.

Civil cross-axis checks from a Flood Week to a judgment-week envelope must be computed component-wise using BC + AD − 1.

Example:

4836 + 65 − 1 = 4900
4831 + 70 − 1 = 4900
4829 + 72 − 1 = 4900

Do not rewrite the statement as a single-point claim such as 4836 BC → AD 70 = 4900 unless the interior event-target state has been declared.

12. Machine Guard Format

12.1 Base form

Machine Guards normally begin with:

Machine Guard [LABEL]:

12.2 Label format

• Machine Guard = two words, capitalized;
• label in square brackets;
• label normally in all caps;
• colon after the closing bracket.

12.3 Allowed extension

A Machine Guard may be followed by optional metadata lines where useful, such as:

• Status:;
• Classification:;
• Scope:;
• Applies to:.

The opening line should remain standardized.

12.4 Prose rule

The directive body should normally remain in prose rather than bullets unless sequential logic truly requires a list.

12.5 Examples of labels already in use

• [JOSEPH EXPLICIT-DERIVATION];
• [JOSEPH HARD-DEDUCTION];
• [MODAL STATE];
• [MOD-5 THEORETICAL];
• [METHUSELAH BIFURCATION];
• [COMPOSITE ALIGNMENT];
• [CROSS-MODAL MIRROR];
• [LIFESPAN VS. CHRONOLOGY FIREWALL];
• [CALENDAR SUFFIXES];
• [SLASH-PAIR SAFETY];
• [RESIDUE PROTOCOL].

12.6 Machine Guard function

A Machine Guard is not rhetorical emphasis. It is a source-control device used to prevent future AI systems or human editors from collapsing a critical distinction.

Use Machine Guards sparingly.

13. Table Conventions

13.1 General table style

Use plain Markdown tables. Keep them readable and structurally simple.

13.2 Preferred abbreviations in tables

Abbreviations are acceptable in tables:

• Act.;
• Rnd.;
• Adj.;
• Beg.;
• Cum.;
• Reg.;
• Diff.;
• Span;
• Anchor.

In prose, spell out the full word unless brevity is clearly preferable.

13.3 Table framing rule

Any table using a non-obvious sign convention, state-layer, or comparison basis should be introduced by a one- or two-sentence framing note immediately before the table.

This framing note should identify as needed:

• sign convention;
• active state;
• methodology;
• scope;
• whether the table is actual, rounded, cumulative, theoretical, comparative, or audit-only.

13.4 Table notes

Table notes should sit immediately below the table.

Use:

*Joseph’s lifespan of 110 is retained here as a textual datum rather than recalculated as a rounded scaffold value.*

Do not bury the note far from the table it qualifies.

13.5 Wide tables

Very wide tables should be simplified where possible. If a table becomes too wide for stable Markdown use, split it into smaller tables rather than forcing excessive width.

13.6 Alignment

Markdown itself does not strongly control visual alignment across platforms. Semantic clarity matters more than visual precision. Numeric columns may be right-aligned in Markdown syntax where supported, but this is secondary.

13.7 Required table audit

During revision, check whether each table has:

• clear active state;
• clear sign convention;
• clear column labels;
• no hidden operator shift;
• no display label substituted for computational state;
• no comma-formatted numbers;
• no ambiguous slash-pairs.

14. Standard Note Labels

Recurring note labels should be kept consistent.

Common labels:

• Note:;
• Methodology:;
• Observation:;
• Footnote (...);
• Cycle frequency note:;
• Cross-reference note:;
• Epistemological note:;
• Audit note:;
• Claim-status note:;
• Appendix note:;
• Publication note:.

14.1 Rule

Use these labels only when they genuinely identify the function of the paragraph. Do not multiply labels unnecessarily.

14.2 Statistical note label

When a section documents a span also flagged by scan material, the preferred opener is:

Cycle frequency note:

This is a preferred formula, not a mandatory heading.

14.3 Audit note label

Use Audit note: when a value, operator, state, or dependency appears uncertain.

Preferred form:

Audit note:
This value appears inconsistent with [specific rule/calculation]. Do not revise silently. Requires author decision.

15. Cross-References

15.1 Internal references

Use section references in the form:

• §4A.7;
• §14.1a;
• §16.2.

For ranges:

• §§4.2–4.5;
• §§A.1–A.4.

15.2 Parenthetical form

Use:

• (see §7.4);
• (§3.4 methodology).

15.3 Cross-file references

At present the repository shows a mixed but stable pattern such as:

• File 11;
• File 31;
• Files 50a–50e;
• File_51_Supplement_A;
• File_51_Supplement_B.

Do not impose a different naming pattern unless the repository is formally normalized later.

15.4 Local preservation rule

Until formal normalization is undertaken, preserve the local file-reference style already in use in the source being edited.

15.5 Cross-file update note

When a revision creates a dependency or changes how a later file should refer to an earlier file, record this in a revision log.

Preferred form:

Cross-file update needed:
File_52c should reference the revised definition of Protocol 1 in Style Guide v2 §18.3.

16. Citation Style

16.1 Biblical citations

Keep biblical citations compact and consistent.

Preferred styles:

• Genesis 41:46;
• Gen 41:46;
• Dan 12:11;
• (Gen 41:46);
• (Dan 12:11).

Use the same book-form consistently within a file or section. Do not mix full and abbreviated forms without reason.

16.2 Extra-biblical citations

Use similarly compact forms for extra-biblical texts:

• 1 Enoch 6;
• Jubilees 1:1;
• Seder Olam Rabbah;
• SOR when used as the repository abbreviation for Seder Olam Rabbah;
• Berossus;
• Sumerian Kings List.

16.3 Multiple references

Group multiple references clearly and sparingly:

• (Gen 41:46; 41:53; 45:6);
• (Exod 12:40; Gal 3:17).

16.4 Use

Citations should support the chronological or textual claim directly. Do not over-cite simple arithmetic once the underlying textual constants have already been established.

16.5 Repository citations

When citing other repository files, preserve the local file-reference style unless the repository later adopts a formal citation system.

17. Mathematical Notation

17.1 Inline math

Use $...$ for inline LaTeX where needed:

• $n$;
• $1 - n$;
• $130 \times 3$.

Simple arithmetic may remain in plain text when perfectly clear:

• 130 × 3 = 390.

17.2 Display math

Use $$...$$ for standalone equations:

$$2580 = 6 \times 430 = 2 \times 1290$$

17.3 Multiplication

Use \times in LaTeX and × in ordinary prose or math text.

Do not use:

• x;
• *;

except where code literally requires it.

17.4 Labels in math

Use \text{} inside LaTeX labels:

$Joseph_{\text{Entry}}$

17.5 Factorization style

Use:

• 23 × 360;
• 6 × 460;
• 70 × 7²;
• (= 60 × 23).

Superscripts should remain true superscripts where possible:

• 5³;
• 40²;
• 70².

17.6 Exact ratio notation

Use exact ratio notation for repository conversions:

• 25/23;
• 70/69;
• 300/299.

Do not convert these ratios into approximated decimal values unless the approximation is itself being discussed.

17.7 Equation density rule

When more than three equations occur in sequence, consider using a table or a short explanatory sentence before the equations.

Dense equation clusters should remain readable and should identify the active anchor, state, or operator before computation begins.

18. Mirror Protocols and Span Operators

18.1 One cross-axis span formula

The repository uses one standard formula for cross-axis spans:

BC + AD − 1

18.2 Separate the span formula from mirror-generation protocol

This distinction is critical.

There is:

• one cross-axis span operator;
• more than one admissible mirror-generation protocol.

Do not blur them together.

18.3 Protocol names

Use:

Whenever a cross-axis calculation appears, specify which protocol is active if the context does not make it obvious.

Use phrasing such as:

• under Protocol 1;
• using the Protocol-2 phase mirror.

18.4 Mirror local-burden rule

In a non-Mirror-focused file, Mirror results normally should not carry the local burden of proof for a claim that can be established internally by same-side arithmetic, textual data, or file-defined chronological states.

This does not mean the Mirror is intrinsically secondary in the repository system. It means the local file should first establish its own internal structure before using the Mirror to complete, confirm, or extend that structure.

Correct:

The internal BJ span of 2450 establishes the primary local structure. The later Mirror recurrence is then classified by function: Mirror coordinate-completion if it completes the active coordinate field, Mirror corroboration if it stress-tests the established structure, or Mirror providential synchronization if it extends beyond demonstrable authorial intent.

Incorrect:

The Mirror recurrence is the first proof that the BJ span is meaningful.

18.5 Mirror claim-status and coordinate-completion

The Mirror is not intrinsically secondary in the repository system. It is secondary only with respect to the local burden of proof in files whose primary topic is not Mirror mechanics.

The repository distinguishes three questions:

When Mirror material appears outside a Mirror-focused file, identify its role using one of the following labels:

Mirror material should not be dismissed as decorative or merely secondary. In a whole-system view, the Mirror is analogous to the second axis in a coordinate plane. A same-side chronological structure may be analyzed independently, but the full repository architecture may require the mirrored/counter-axis in order to disclose the complete pattern.

Therefore, avoid blanket statements such as:

Mirror material is secondary / appendix-only.

Prefer:

In this non-Mirror file, Mirror material does not carry the local burden of proof. Where it completes the coordinate structure, it is classified as Mirror coordinate-completion. Where it only confirms or extends the established structure, it is classified as Mirror corroboration or appendix-only material.

18.6 Mirror vs inverse-number material

Mirror material and inverse-number material are not equivalent.

The Mirror functions as a cross-axis coordinate field of the repository. It may be required for full-system interpretation even when it is not required to prove the local thesis of a non-Mirror file.

The inverse-number operator is a derived transformation. It reverses base-10 digit structures and tests whether a span, node, or trunk preserves coherence under inversion. Unless a file is explicitly inverse-focused, inverse material should normally remain appendix-only or secondary corroboration.

Do not treat inverse material as having the same system-level status as the Mirror unless the file explicitly narrows itself to inverse-number mechanics.

Correct:

The Mirror result completes the cross-axis coordinate identity of the Luke/Jared node and is therefore classified as Mirror coordinate-completion. The inverse landing is retained as appendix-only because File_54 is not an inverse-focused file.

Incorrect:

Mirror and inverse material are both secondary appendix-only observations.

19. Naming Specific States

19.1 First-use full descriptor

On first use within a section, give the full descriptor when ambiguity is possible.

Examples:

• Scaffold +60 base anchor: 4166 BC;
• MT Year-6 anchor: 4116 BC;
• Upper rounded MT +60 Creation boundary: 4171 BC;
• Mirror target of the MT Year-6 anchor: AD 4115;
• Transmitted SP lower rounded boundary: 4411 BC.

19.2 Short reuse

After the full descriptor has appeared within the same section, a shortened form may be used if ambiguity is low.

19.3 Across sections

Do not assume a short form remains clear across section boundaries. Restate the full descriptor when entering a new dense section.

19.4 Specificity hierarchy

When naming a state, prefer specificity in this order:

1. chronological tradition;
2. state-type;
3. variant or overlay;
4. node-class;
5. date.

Example:

MT rounded +30 Apparent Age Creation anchor: 4136 BC

20. State-Status Terms

20.1 Preferred terms

Use these carefully and consistently:

• transmitted state;
• alternate state;
• working state;
• comparison state;
• modal state;
• local comparison state;
• display label;
• computational state;
• secondary overlay;
• appendix-only state.

20.2 Use

If one state is adopted for the current file while another is acknowledged but not used, say so explicitly.

Example pattern:

• transmitted SP state = working state in this file;
• alternate local option = noted but not adopted.

20.3 Do not collapse states

Avoid editorial revisions that turn distinct states into vague alternatives.

Incorrect:

The date may be 4416 or 4411 BC.

Correct:

The transmitted SP rounded Creation block is 4416/4411 BC. The pair functions as an ordered block, not as an ordinary uncertainty range.

21. Prose Style

21.1 Default form

Default to prose paragraphs.

21.2 Use lists sparingly

Lists are appropriate for:

• genuine series of 3 or more items;
• summary sections;
• compact procedural sequences;
• audit checklists;
• table-framing aids.

Do not overuse lists for material that is better expressed as direct prose.

21.3 Human-readable but AI-forward

Source files should remain readable to humans, but their primary obligation is structural clarity for AI and future revision.

That means:

• short logical units;
• explicit state-tags;
• explicit sign conventions;
• minimal prose drift;
• no fluff;
• no hidden operator changes;
• no unexplained modal transitions.

21.4 Paragraph control

Dense paragraphs should be decompressed when they contain multiple state shifts, operator shifts, or claim-status shifts. Decompression should clarify the logic without diluting technical precision.

22. Appendix Policy

22.1 Function of appendices

Appendix material should be used for:

• secondary corroboration;
• providential overpattern;
• Mirror stress-tests;
• statistical scans;
• weak but useful observations;
• technical derivations that would interrupt the main argument;
• exploratory calculations not yet promoted into the main thesis.

22.2 Primary claim rule

Appendix material must not carry the primary claim unless explicitly promoted into the main body.

22.3 Appendix-only label

When material is useful but not load-bearing, label it as appendix-only.

Example:

Claim-status note:
This observation is appendix-only. It may clarify the larger pattern but does not carry the main argument.

22.4 Weak observation rule

Weak observations may be retained as footnotes or appendix notes if they clarify a stronger point. They should not expand the main argument.

22.5 Providential pattern rule

Providential synchronization may be recorded when arithmetic is exact and the symbolic relation is coherent. It must be labeled separately from authorial intent.

23. Publication-Layer Notes

23.1 Markdown does not enforce editorial correctness

Markdown handles structure. It does not itself enforce:

• capitalization;
• no commas in numbers;
• hyphenation policy;
• terminology discipline;
• modal-state consistency;
• claim-status discipline;
• arithmetic correctness.

Those are repository style rules and must be maintained editorially.

23.2 WordPress conversion

When converting to WordPress:

• preserve section numbers;
• preserve heading hierarchy;
• preserve table structure where possible;
• preserve math notation;
• preserve no-comma number formatting;
• preserve BC/AD formatting;
• do not let WordPress become the editing source again.

23.3 PDF and DOCX conversion

PDF and DOCX outputs are derived publication forms. They may improve visual presentation, but they must not become the source of future textual revision unless converted back into Markdown and audited.

24. File Intake Sheet

24.1 Required intake sheet for revision projects

Before revising a file, create a compact intake sheet.

Recommended form:

# File Intake Sheet

File:
Current title:
Current source format:
Current status:
Primary topic:
Primary anchors:
Major traditions involved:
Major ratios/operators:
Dependencies:
Known unresolved issues:
Revision priority:
Risk level:

24.2 Function

The intake sheet prevents the revision process from beginning with prose smoothing before the file’s state, dependencies, and risks are understood.

24.3 Intake rule

For high-risk or critical files, complete the intake sheet before rewriting any prose.

25. Risk Rating

25.1 Required risk rating

Assign a risk rating before editing.

25.2 Dependency-blocked files

If a file depends on missing operators, undefined Prime constants, or unavailable prerequisite files, do not invent the missing structure.

Use:

Audit note:
This section depends on [missing file/operator/constant]. Do not infer. Mark as dependency blocked until the prerequisite is supplied.

25.3 High-risk workflow

For high-risk files, use a two-step revision process:

1. produce audit and revision plan;
2. revise after the audit is accepted or clarified.

26. The Do-Not-Break-the-Repository Rule

When revising, never silently change:

• an anchor date;
• a span;
• a modal state;
• a node-class;
• a sign convention;
• an operator;
• a mirror protocol;
• a Cainan / +60 / +215 / +30 state;
• a rounded vs actual distinction;
• a regular vs cumulative distinction;
• a transmitted vs alternate state;
• a display label vs computational state;
• a primary argument into an appendix-only claim, or the reverse.

If a file contains an apparent error, mark it as:

Audit note:
This value appears inconsistent with [specific rule/calculation]. Do not revise silently. Requires author decision.

Precision outranks smoothness. Repository continuity outranks local elegance.

27. Per-File Revision Workflow

Every file goes through the same consolidated workflow (Project Procedures v3.0).

27.1 Pass 0 — Intake + Mechanical Lint

Create or update the File Intake Sheet (§24). Assign risk level: Low, Medium, High, or Critical (§25). Run the mechanical lint and attach its report. Produce the section-level revision plan, early audit notes, and controlling exemplar(s). No revision occurs in Pass 0.

27.2 Pass 1 — Unified Revision Pass

One controlled rewrite applying the five editorial layers of §2A simultaneously: Structural, Terminology, Modal-State, Arithmetic, Argument. All content invariants apply (Machine Guard [UNIFIED PASS INVARIANTS]).

Deliverables: revised Markdown; audit notes; unresolved issues; recommended cross-file updates; Revision Log.

High-risk split: for High or Critical risk ratings, Pass 1 divides once — Structural + Terminology + Modal-State first, then Arithmetic + Argument.

27.3 Pass 2 — Verification Pass

1. Machine diff between source file and revised file.
2. Audit of the diff by change class: every change must be formatting, terminology, or an explicitly logged correction; nothing outside those classes may have changed.
3. Scripted arithmetic recheck where spans and products are parseable; mismatches become Audit note: candidates, never silent corrections.
4. Consolidated Author-Decision list: every reserved item presented once, recommendation first.

27.4 Finalization

Only when the author says to mark the file Final. Same content as the former Finalization Pass: set Status: Final; remove temporary pass-language; retain necessary audit and dependency notes; update the Revision Log; list unresolved issues and required cross-file updates; verify the File map; verify no derived-AI-format reshaping. Then offer a pressure test.

27.5 Publication Pass

Prepare derived publication format only after Markdown is stable (§2A.6).

27.6 Revision Log

After revision, record:

Revision Log:
- date
- passes completed
- unresolved issues
- author decisions needed
- cross-file updates required

27.7 Vocabulary registration

When a file is finalized, register its new state vocabulary, convention updates, and Machine Guards in the State Vocabulary Register, and append the Update Record to the Repository_Change_Archive. The Style Guide and Project Procedures receive at most a one-line status pointer; they no longer absorb per-file vocabulary.

28. Repository Review Order

Do not revise files in numerical order only. Review them in dependency order.

28.1 Recommended dependency order

28.2 Pilot set

Start with a small pilot batch before revising everything.

Recommended pilot:

28.3 Second batch

After the pilot:

28.4 Reason for dependency order

The newer files already embody the current standard and should become stable exemplars before older files are rewritten.

29. Repository-Wide Control Files

29.1 File Inventory Table

Create a master table:

29.2 Master Anchor Table

Create one cross-file table for repeated anchors:

Examples of anchors to include:

• 1406 BC;
• 1446 BC;
• 1399 BC;
• 4106 BC;
• 4116 BC;
• 14006 BC;
• 6 BC;
• AD 1405;
• AD 29515.

29.3 Modal-State Glossary

Create a controlled glossary for:

• actual;
• rounded;
• regular;
• cumulative;
• transmitted state;
• alternate state;
• endpoint;
• anchor;
• boundary;
• block;
• envelope;
• mirror target;
• apparent-age overlay;
• restored 2nd Cainan;
• Cainan expunged;
• Protocol 1;
• Protocol 2;
• Priestly 336-day Ledger state;
• 24-course roster source-control state;
• seven-day service-period state;
• Sabbath transition-boundary state;
• Priestly-Enochian bridge corollary;
• Priestly-Enochian half-week straddle;
• source-control bibliography vector;
• Christological joint-file state;
• Second-Adam / Jan-1 covenant numeric-year Mirror;
• phase-resolved paired Mirror coordinate-completion;
• File_13 Passion-date pair state;
• File_13 day-year purification display;
• Matthew exile-bearing Abraham head bracket;
• cumulative MT Shem / Noah Mirror state;
• LXX actual Creation endpoint state;
• LXX actual Year-6 state;
• AD 33n / AD 30n / AD 33t / AD 34 display-state firewall.
• Rod of Enoch state.
• Pi master-formula state.
• Pi convergent generator state.
• AD 33 solar synchronization state.
• Samaria Node schematic envelope state.
• actual Fall of Samaria state.
• Israel literal-reign schematic ledger.
• Samaria / Jerusalem twin-city judgment vector state.
• Samaria Node / Immanuel 720 overlay state.
• Samaria Node three-tradition Creation overlay state.
• Abrahamic 240-cycle overlay state.
• Samaria Node sub-year marker exploratory note.

File_18 adds the following glossary candidates to the controlled state-register layer:

• raw data source state;
• minimum baseline table state;
• source-table state;
• shared year-label state;
• envelope member-label;
• phase-resolved envelope member;
• website-to-minimum adjustment state;
• SP Shem Superposition;
• Abraham / Terah four-position field;
• 2nd Cainan variant-boundary state;
• Pentateuchal Funnel / all-even structural harmony state;
• Cainan macro-vector B6 state;
• audit-controlled 2307 / solar companion state;
• File_18 LXX corrected source-table state;
• MT cumulative Peleg phase-resolved Mirror application;
• SKL display-state rail dependency;
• File_18 / File_21 Etana SKL opening-anchor state.

File_34 adds the following glossary candidates to the controlled SKL / Berossus state-register layer:

• File_34 post-final citation-control state;
• Berossus computational-anchor state;
• fall-of-Babylon / restoration / Berossus-anchor three-state field;
• Precessional Envelope state;
• Cosmic Pixel state;
• SKL base / rail firewall;
• SKL-to-Berossus 2370 corridor state;
• 30 + 20 + 30 restoration corridor;
• paired slash-display arithmetic;
• Nisan / Tishri phase-chain arithmetic;
• Appendix B phase-chain dependency state;
• Pillar / AD target state;
• Sanctuary Fractal / Key-of-23 expansion state;
• authorial forward-time plus display;
• expansion difference / non-Residue state;
• state-conditioned SKL +1260 display.

29.4 Cross-File Dependency Register

For every file, record:

This is especially important for Prime Files 29–41.

30. Practical AI Revision Prompt

Use this prompt template for each file revision:

You are revising File_[number] under 490d Repository Style Guide v2.5, Project Procedures v3.0, the Restart Capsule, and the State Vocabulary Register entries active for this file.

Pass 0 (this turn): produce only the File Intake Sheet, risk rating, lint report, revision plan, early audit notes, and controlling exemplar(s). Do not revise.

Pass 1 (next turn): one Unified Revision Pass applying the Structural, Terminology, Modal-State, Arithmetic, and Argument layers simultaneously.
1. Preserve all arithmetic, anchors, modal states, node-classes, sign conventions, operators, Mirror protocols, and theological claims unless a clear inconsistency is identified.
2. Normalize Markdown structure, headings, terminology, number formatting, BC/AD format, table framing, and math notation.
3. Identify but do not silently fix uncertain arithmetic; use Audit note: / Dependency note:.
4. Label claim-status where needed.
5. Return: revised file text; audit notes; unresolved issues; recommended cross-file updates; Revision Log.

Pass 2 (final turn): Verification Pass — machine diff against the source, change-class audit, arithmetic recheck, consolidated Author-Decision list.

End every response with a Next Step statement.

For High or Critical risk files, split Pass 1: layers 1–3 in one turn, layers 4–5 in the next.

31. Modal-State Glossary: Working Definitions

Generic, repository-wide states are defined here (§31.1–§31.37). All file-specific entries — former §31.38–§31.167 — were migrated verbatim, numbering preserved, to the State Vocabulary Register v1.0. Read any cross-reference to Style Guide §31.38–§31.167 as State Vocabulary Register §31.38–§31.167.

31.1 Actual

An unrounded chronological state, usually referring to the textual or computed chronology before rounded scaffold adjustment.

31.2 Rounded

A scaffolded or rounded chronological state used for structural comparison, mod-5 analysis, or larger repository architecture. A rounded state is not automatically a literal chronology. When the term refers to the Rounded Scaffold, it belongs to the methodological mod-5 comparison layer unless the active file explicitly promotes it into its own argument.

31.3 Regular

The standard patriarchal or biblical chronological line as distinct from the cumulative chronology.

31.4 Cumulative

A chronology produced by accumulating lifespans or spans end-to-end rather than using ordinary begetting chronology.

31.5 Transmitted state

The state preserved in the textual or traditional form being used as the working datum.

31.6 Alternate state

A recognized variant or local option that is acknowledged but not necessarily adopted as the working state.

31.7 Endpoint

A terminal date or boundary in a span, block, envelope, or structural sequence.

31.8 Anchor

A date that governs or stabilizes a calculation, file, system, or structural comparison.

31.9 Boundary

A date functioning as the edge of a block, envelope, phase, or chronological range.

31.10 Block

A structured pair or set of dates treated as a coherent unit.

31.11 Envelope

A range or spread that contains phase-resolved or multiple valid internal states.

31.12 Mirror target

The corresponding date or state produced by a Mirror protocol.

31.13 Apparent-age overlay

A secondary overlay, especially the +30 Apparent Age of Adam, applied only where the file explicitly defines it as active.

31.14 Restored 2nd Cainan

A chronological state in which the 2nd Cainan is retained or restored as a valid component.

31.15 Cainan expunged

A chronological state in which the 2nd Cainan is omitted or removed from the active computation.

31.16 Protocol 1

Pure rounded A-space integer mirror.

31.17 Protocol 2

Tishri/Nisan phase mirror, midpoint-pivot.

31.18 Nisan-state label

A calendar-state display label marked by suffix n. It identifies a Nisan / spring state where the local file uses suffixed dates. It is not automatically a .5 computational state.

31.19 Tishri-state label

A calendar-state display label marked by suffix t. It identifies a Tishri / fall state where the local file uses suffixed dates. It is not automatically a .5 computational state.

31.20 Physical residue

Actual day-drift against the Residue Protocol calibrated solar year S_K, computed as N / 40 days when the Residue Protocol is explicitly active.

31.21 Conceptual residual-display

A liturgical or day-year display value generated by passing physical residue through the same Key-of-23 ratio that governs the corresponding year conversion. It is not physical drift and must not be fed back into ordinary date arithmetic.

31.22 Residual day-year lift

The conceptual operation by which residue-days echo residue-years. Example: 6.9 years × 70/69 = 7 years; therefore 6.9 physical residue-days may display as 7.0 residual-display days under the day-year analogy.

31.23 MT Minimum-Regular

The forward-most regular MT comparison state. In File_02, the MT Minimum-Regular Flood is 2243 BC.

31.24 MT Standard-Normal

The normative operating MT state under the full 430 years in Egypt and without +60 Terah. In File_02, the MT Standard-Normal Flood is 2458 BC.

31.25 Cumulative Flood Week

A cumulative week-of-years envelope. In File_02, the base rounded cumulative Flood Week is 4836–4829 BC, and the restored cumulative 2nd Cainan Flood Week is 5296–5289 BC.

31.26 Judgment-week envelope

The AD-side envelope paired with a cumulative Flood Week by civil cross-axis arithmetic. In File_02, the judgment-week envelope is AD 65–72, with AD 70 as the primary internal event-target.

31.27 Sumerian A / SKL Short

The SKL state in which the 23 kings have the whole-year total 17980. The Physical state begins at 20886 BC and is anchored to 2906 BC.

31.28 Sumerian B / SKL Long

The SKL state in which the 23 kings have the whole-year total 24510. The Physical state begins at 27366 BC and is anchored to 2856 BC.

31.29 SKL +30 Apparent Mode

A global SKL mode rail shifting the SKL beginning-and-anchor pair by 30 years while preserving the whole-year total.

31.30 SKL +2 local rail

A local two-year SKL rail shifting the beginning-and-anchor pair by two years while preserving the whole-year total. It is related to the +720 scale-state but must not be substituted for it without an explicit scale shift.

31.31 SKL +720 scale-state

The cosmic SKL/Berossus expression related to the +2 local rail through 2 years = 720 days. It appears as a +720 or ±720 year rail only when the file explicitly shifts into SKL/Berossus cosmic scaling.

31.32 Whole-year total

The integer SKL total used for local arithmetic when an appended month/day textual datum is preserved but dependency-controlled. In File_02, the whole-year totals are 17980 and 24510.

31.33 Appended month/day textual datum

The SKL phrase 3 months and 3.5 days, preserved in addition to the whole-year total. Its full function remains dependency-controlled by File_34 unless a file explicitly opens that operator.

31.34 File map

A terse functional index near the top of a repository file. It identifies where major logic, states, operators, or dependency controls are located. It is not a decorative table of contents.

31.35 Rounded Scaffold forward reference

A clarity-only reference to a Rounded Scaffold value before the Rounded Scaffold is directly opened by File_51a or a later rounded-focused file. Its purpose is to prevent state confusion, not to make the rounded value a literal chronology.

31.36 State-safe retrieval

A retrieval condition in which a section, paragraph, table, File map entry, Machine Guard, or appendix note is retrieved together with enough local context to identify the active state, node-class, operator, chronological tradition, claim-status, and dependency status.

31.37 Derived AI format

Any AI-facing format generated from the canonical Markdown source, including RAG index records, embedding metadata, Knowledge Graph records, JSON exports, JSONL training pairs, or prompt/response datasets. Derived AI formats must preserve source meaning and must not become the canonical source.

31.38–31.167 Per-file states (migrated)

Migrated verbatim to State_Vocabulary_Register v1.0, Part A, numbering preserved. The Register entries are active controls of equal authority. New per-file states register there, not here.

32. File 51-Derived Standard Summary

The strongest standards derived from File 51 are these:

1. no commas in numbers or dates;
2. preserve modal states rather than collapsing them;
3. define sign conventions locally;
4. distinguish node-classes explicitly;
5. preserve exact half-year states internally;
6. separate mirror-generation protocol from cross-axis span operator;
7. distinguish same-side subtraction from cross-axis arithmetic;
8. use restrained Markdown as the canonical source;
9. keep prose exact, spare, and non-inflated;
10. frame dense tables before presenting them;
11. restate state-tags when a dense paragraph changes system or node-class;
12. do not silently repair values that require author decision.

33. Final Governing Principle

The revision program must not make the repository smoother at the expense of precision. It must make every file more explicit about its active state, node-class, arithmetic operator, claim-status, and dependency structure.

The desired result is a Markdown-first corpus that human readers can follow and advanced AI systems can parse, retrieve, and transform without collapsing modal states, inventing missing dependencies, confusing publication formatting with source authority, or treating derived AI formats as canonical source.

The governing rule is therefore:

clarify the logic, preserve the terminology, reduce compression, add no ornament.

And the governing safeguard is:

do not silently change the repository’s arithmetic, anchors, modal states, node-classes, operators, sign conventions, or mirror protocols. If a value appears wrong, mark it for audit rather than correcting it without review.

34. Revision Log: v2.5

Revision Log — August 3 2026 File_65 companion-pointer refresh

• Revision date: August 3 2026.
• Scope: pointer-only maintenance after Final File_65, Register v1.36, Capsule v11.35, Archive v1.45, reciprocal source replacements, and manifest v17 preparation.
• Changes: active companion pointers advanced to State Vocabulary Register v1.36, Restart Capsule v11.35, and Repository Change Archive v1.45; Revision date refreshed; no Style Guide rule or generic control changed.
• Historical pointer restraint: the July 27 record remains v11.34 / v1.35 / Archive v1.43 as the historical state of that event.
• Status: Style Guide remains v2.5.

Revision Log — August 8 2026 File_66 amendment companion-pointer refresh

• Style Guide version remains v2.5; no editorial rule, terminology standard, Machine Guard format, number-formatting rule, claim-status category, Mirror protocol, arithmetic control, workflow rule, or publication policy changed.
• Companion pointers advanced to State Vocabulary Register v1.38, Restart Capsule v11.37, Repository Change Archive v1.47 addendum / assembly package, and Publication Manifest v19 after the coordinated File_66 August 5–7 amendment registration.
• Project Procedures remains v3.5.
• The pointer refresh is bounded maintenance only; all non-header/non-log Style Guide content is preserved from the supplied v2.5 source.

Revision Log — August 10 2026 File_67 companion-pointer refresh

• Style Guide version remains v2.5; no editorial rule, terminology standard, Machine Guard format, number-formatting rule, claim-status category, Mirror protocol, arithmetic control, workflow rule, or publication policy changed.
• Companion pointers advanced to State Vocabulary Register v1.39, Restart Capsule v11.38, Repository Change Archive v1.48, and Publication Manifest v20 after File_67 registration and release preparation.
• Project Procedures remains v3.5.

Revision Log — August 13 2026 File_68 companion-pointer refresh

• Style Guide version remains v2.5; no generic Style Guide rule changed.
• Companion pointers advanced to State Vocabulary Register v1.40 and Restart Capsule v11.39 after Final File_68 registration and eight reciprocal-source updates.
• Archive v1.48 / Manifest v20 remained the pending publication layer at this historical step.

Revision Log — August 15 2026 File_67–File_68 publication-pointer closure

• Style Guide version remains v2.5.
• Active companion pointers are now State Vocabulary Register v1.40, Project Procedures v3.5, Restart Capsule v11.39, Repository Change Archive v1.49, and Publication Manifest v21.
• Scope is pointer-only maintenance. No Style Guide rule, terminology standard, Machine Guard format, number-formatting rule, claim-status category, Mirror protocol, arithmetic control, workflow rule, publication policy, or dependency boundary changed.

Revision Log — August 17 2026 File_69 control-pointer refresh

• Style Guide version remains v2.5; no generic Style Guide rule changed.
• Companion pointers advanced to State Vocabulary Register v1.41 and Restart Capsule v11.40 after Final File_69 registration.
• Project Procedures remains v3.5. Repository Change Archive v1.49 and Publication Manifest v21 remain the current File_67–File_68 publication controls pending File_69 release work.
• Scope is pointer-only maintenance. No Style Guide rule, terminology standard, Machine Guard format, number-formatting rule, claim-status category, Mirror protocol, arithmetic control, workflow rule, publication policy, or dependency boundary changed.

Revision Log — August 25 2026 renewed Final File_70 pointer refresh

• Style Guide version remains v2.5.
• Active companion pointers advance to State Vocabulary Register v1.49 and Restart Capsule v11.48 after renewed author-invoked Finalization of File_70.
• Repository Change Archive v1.52 and Publication Manifest v24 remain non-controlling prior release records pending later author-directed regeneration.
• No Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed.

Revision Log — August 27 2026 File_70 Supplement A control-pointer refresh

• Style Guide version remains v2.5.
• Active companion pointers advance to State Vocabulary Register v1.50 and Restart Capsule v11.49 after central registration of renewed Final File_70 Supplement A and the current File_70 reciprocal guard.
• Repository Change Archive v1.52 and Publication Manifest v24 remain non-controlling prior release records pending later author-directed regeneration.
• Scope is pointer-only maintenance. No Style Guide rule, terminology standard, Machine Guard format, number-formatting rule, claim-status category, Mirror protocol, arithmetic control, workflow rule, publication policy, or dependency boundary changed.

Revision Log — September 6 2026 Sothic/365-day companion control-pointer refresh

• Style Guide version remains v2.5; generic rules and body are unchanged.
• Active control pointers advance to State Vocabulary Register v1.52 and Restart Capsule v11.51.
• Registration covers the bounded Sothic/365-day states/guards and File_18 Lamech-188 audit-only classification.
• Repository Change Archive v1.52 and Publication Manifest v24 remain prior non-controlling release records pending later publication maintenance.
• No Style Guide rule, terminology standard, Machine Guard format, arithmetic control, workflow rule, publication policy, or dependency boundary changed.

Revision Log — September 8 2026 Lamech control-pointer refresh

Current pointers advance to State Vocabulary Register v1.53 §D.43 and Restart Capsule v11.52 for the author-directed Lamech settlement. Style Guide remains v2.5; all generic rules and the prior body are unchanged. No archive/manifest regeneration, pressure test, or deployment is claimed.