File: Project_Procedures Title: 490d Repository Style Harmony — Project Procedures for File Revision Status: Revised control file; v3.2 — §18 Novelty Verification Rule added June 11 2026 (author-approved bounded update; precedent: the File_38 `1661 BC` correction); v3.1 — §17 Context Economy added June 10 2026 (token-cost controls; tiered file-loading per the File Cheat Sheet & Load Priority); v3.0 consolidated-workflow update under Repository Revision Plan v3.0 (author-approved June 10 2026); six-pass sequence replaced by Pass 0 (Intake + Mechanical Lint), Pass 1 (Unified Revision Pass with five editorial layers), Pass 2 (Verification Pass with machine diff); all content invariants, authorial-direction protocol, Machine Guards, and dependency boundaries retained unchanged; per-file control vocabulary routed to State_Vocabulary_Register v1.0; historical Update Records migrated to Repository_Change_Archive v1.0; diff-audited June 10 2026 Primary domain: Methodological Canonical source: Markdown Revision basis: 490d Repository Style Guide v2.5; Restart Capsule v11.2; State_Vocabulary_Register v1.0; Repository Revision Plan v3.0; Project Procedures v2.4 (prior version, retained unaltered) Related files: 490d Repository Style Guide v2.5; State_Vocabulary_Register v1.4 (current edition); Repository_Change_Archive; Restart Capsule v11.5 (current edition); File_00; File_51a; File_54 Per-file controls: the per-file operator and modal-state vocabulary formerly enumerated in this header (File_02, File_22, File_32, File_33, File_34, File_35, File_36, and later files) is registered in the State_Vocabulary_Register v1.0 and remains fully binding where the target file opens those states. Load the Register entries relevant to the target file at the start of each revision chat. # 490d Repository Style Harmony — Project Procedures for File Revision Use this control file at the start of each repository-file revision chat, together with the Style Guide v2.5, the Restart Capsule, and the State Vocabulary Register entries active for the target file. The purpose of this file is procedural. It governs how a file is revised inside the Project. It does not replace the Style Guide, Restart Capsule, State Vocabulary Register, File_00, File_51a, File_54, or any file-specific source. Those files remain the controlling context for their own domains. ## 1. Task Frame Revise the attached repository file under the consolidated three-turn workflow of §6, while using `File_00 Final` as the constant foundational example, `File_51a Final` as the foundational procedural and Rounded Scaffold precedent, and `File_54 Final` as the current later-file style-control exemplar. Use the Project knowledge files already available in this Project, especially: - `490d Repository Style Guide v2.5`; - `Restart Capsule v11.2`; - `State_Vocabulary_Register v1.0` — load the entries active for the target file; - `File_00 Final — Repository Foundation, Axiom Engine, and Source Map`; - `File_51a Final` and `File_54 Final` as exemplars; - the finalized file named by the Register as controlling precedent for any state the target file opens (for example `File_02 Final` for Flood/SKL states, `File_32 Final` for prime-polarity states, `File_34 Final` for SKL / Berossus states). Do not rewrite the target file before Pass 0 is approved. ## 2. Control-File Boundary The Restart Capsule, Style Guide, and State Vocabulary Register are context and control documents. Do not revise either document during an ordinary repository-file revision unless the author explicitly asks for those control files to be changed. If a target file appears to require a cross-file control update, record it under `Recommended cross-file updates`. Do not silently alter the Style Guide, Restart Capsule, State Vocabulary Register, or another repository file. Derived AI formats are also outside the ordinary file-revision target. Do not convert a repository file into JSON, JSONL, prompt/response pairs, Knowledge Graph records, or RAG metadata unless the author explicitly requests that derived extraction task. ## 3. Control Hierarchy For repository file revisions, use the following hierarchy: 1. `490d Repository Style Guide v2.5` governs source formatting, terminology, modal-state control, claim-status handling, Mirror classification, inverse-number firewalling, Residue Protocol handling, Flood/SKL terminology, and revision standards. 2. `Restart Capsule v11.2` governs repository-wide chronology, anchors, operators, modal states, and cross-file dependencies. 3. `State_Vocabulary_Register v1.0` governs per-file modal-state vocabulary, per-file convention updates, and per-file Machine Guards. Register entries carry the same authority they carried in Style Guide v2.4. When the target file opens a state defined in the Register, the named source file (`File_02 Final`, `File_22 Final`, `File_32 Final`, `File_33 Final`, `File_34 Final`, `File_36 Final`, and so on) remains the controlling precedent for that state exactly as under v2.4. 4. This Project Procedures file governs the required workflow and authorial-direction protocol. 5. `File_00 Final` is the constant foundational example, especially for repository-wide file-function framing, source-map discipline, file-level modal-state registers, Machine Guards, arithmetic-control / argument-control / content-scope controls, calendar-state suffixes, slash-pair expansion, Mirror / civil / inverse firewalling, Residue Protocol distinction, SKL/Berossus dependency discipline, and appendix-only scope control. 6. `File_54 Final` is the current later-file style exemplar, especially for Mirror coordinate-completion, Mirror corroboration, Mirror appendix-only, inverse-number appendix-only, and claim-status control. 7. `File_51a Final v2.1 Refresh` remains the foundational procedural and Rounded Scaffold precedent, especially for modal-state tables, Machine Guards, statistical scan handling, and File_51–52 dependency logic. If `File_00`, `File_51a`, and `File_54` appear to differ in Mirror or inverse-number handling, first distinguish file function. `File_00` defines the repository foundation and Mirror entry protocol. `File_54` models Mirror classification in a later non-Mirror comparative file. `File_51a` remains the procedural and Rounded Scaffold precedent. Prefer the current Style Guide and the local file function. Do not import `File_00`'s foundational Mirror status into every non-Mirror file automatically. ## 4. Governing Rules Preserve all arithmetic, anchors, modal states, node-classes, operators, sign conventions, slash-pairs, ranges, blocks, envelopes, Mirror protocols, theological claims, and cross-file dependencies unless a clear inconsistency is identified. Where prime-grid polarity or Mirror language is active, identify the `File_32` namespace before revising: raw prime-space cross-polarity, positive-polarity date output, negative-polarity / signed A-space date output, rails-space `B/M`, P2 positive rail-window, P2 negative-polarity / signed A-space bridge, Coordinate Mirror / Protocol 1, rounded / mod-10 display, or later dependency-controlled operator. Positive and negative prime-date outputs are the primary Prime–Civil Interface layer where opened. Coordinate Mirror is secondary agreement unless the local file explicitly gives Mirror proof burden. Where File_33 source tables use `Mirror Date` under ordinary `B/M`, treat it as the `M` rail / apparent rail, not Coordinate Mirror. Do not introduce a generic `+10 Year Mirror Jump`; unsupported local examples were deleted from File_33 active proof. Where File_34 SKL / Berossus language is active, identify whether the local section opens File_34's full derivation, a local SKL table value, a Berossus computational anchor, an Appendix B phase-chain state, a Pillar / AD target state, or a citation-control reference only. Preserve `486 BC` as Berossus computational anchor, `536 BC` as restoration anchor, and `539t/538n BC` as fall / Persian-transition field. Preserve paired slash-displays, the `2370` corridor, and the `30 + 20 + 30` restoration corridor without converting them into ranges or failed `30`-year spans. Do not silently correct arithmetic or modal-state logic. If a value, operator, state, dependency, or claim appears uncertain, add an `Audit note:` or `Dependency note:`. Maintain no-comma number formatting: - `14006 BC`; - `12600`; - `AD 1405`. Distinguish same-side spans from cross-axis spans. Cross-axis civil spans use: ```markdown BC + AD − 1 ``` Preserve modal states rather than collapsing them. Preserve calendar-state suffixes such as `n` and `t` as state labels unless the local file explicitly converts them into exact phase-resolved values. Preserve slash-pairs and ranges as modal or display states. Do not collapse a slash-pair into a single date unless the local file explicitly resolves that state. Restate active state, node-class, tradition, operator, or Mirror protocol whenever the argument shifts. Treat Mirror material by local file function. In `File_00`, Mirror material is foundational because `File_00` defines the repository Mirror entry protocol. In later non-Mirror files, classify Mirror material locally as Mirror coordinate-completion, Mirror corroboration, Mirror appendix-only, Mirror providential synchronization, or another Style Guide category. Keep the civil cross-axis span operator, Mirror protocol, 10x Mirror scaling, and inverse-number reversal distinct. Keep the Rounded Scaffold / rounded root chronology separate from actual and local-state chronologies. 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 File_51a 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 Rounded Scaffold values. 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. Distinguish ordinary Key-of-23 whole-year conversion from the Residue Protocol. Invoke residue arithmetic only where the file explicitly shifts into physical residue, conceptual residual-display, or residual day-year lift. Treat statistical scans as `Statistical result` or `Exploratory diagnostic` unless recomputation is explicitly requested. Do not perform pressure testing unless the author explicitly requests it. ## 5. Authorial-Direction Protocol Before asking the author for clarification or approval, first think the issue through from the governing files, the local file function, and the arithmetic already supplied. If the best solution is clear or highly probable, recommend and apply that solution within the active pass rather than interrupting the workflow for approval. This is treated as assumed authorial affirmation, not as silent alteration. Record the rationale in the pass notes, audit notes, or revision log where appropriate. If the issue involves a genuinely doubtful authorial choice, present the best recommended solution first, then mark the item for an Author-Decision Pass. Do not ask an open-ended question when a controlled recommendation can be made. If the math, derivation, state-shift, or claim is not understood, say so directly. Do not smooth, infer, or repair what is not understood. Add an `Audit note:` or `Dependency note:` that states exactly what is unclear. Only bring authorial approvals to the author when the issue remains truly in doubt after the best controlled solution has been developed. ### 5.1 Authorial-Decision Thresholds | Situation | Handling | |---|---| | Formatting, terminology, heading normalization, no-comma numbers, BC/AD normalization | Apply directly under assumed authorial affirmation | | Clearly required update from current Style Guide or Restart Capsule | Apply directly and record in notes or Revision Log | | Clear local inconsistency with an active Machine Guard | Apply only if the correction is procedural; otherwise mark with `Audit note:` and recommend the fix | | Apparent arithmetic error with unambiguous correction | Recommend the correction; apply only if the current pass permits correction and the file logic is not altered; otherwise mark for audit | | Unclear derivation, unclear operator, unclear state, or unclear provenance | Do not infer; add `Audit note:` or `Dependency note:` | | Substantive interpretive choice with more than one plausible repository-compliant option | Recommend the best option and reserve for Author-Decision Pass | | Theological or typological claim whose status is unclear | Preserve if textually anchored; label by claim-status; flag only if its function remains doubtful | Machine Guard [AUTHORIAL DIRECTION]: Do not use authorial approval as a substitute for analysis. First identify the best repository-compliant solution. Assume affirmation where the solution is high-probability and non-disruptive. Ask for author decision only when the issue remains genuinely doubtful or when the math / source logic is not understood. ## 6. Required Workflow Proceed in three turns per file: 1. **Pass 0 — Intake + Mechanical Lint.** Intake, risk rating, lint report, revision plan. No revision. 2. **Pass 1 — Unified Revision Pass.** One controlled rewrite applying the five editorial layers (Style Guide §2A): Structural, Terminology, Modal-State, Arithmetic, Argument — section by section, under all content invariants and the layer controls of §11. 3. **Pass 2 — Verification Pass.** Machine diff against the source; change-class audit; scripted arithmetic recheck; consolidated Author-Decision list. Finalization (§11.6) occurs only when the author says to mark the file Final. Risk-tiered fallback: for High or Critical risk ratings, Pass 1 divides once — Structural + Terminology + Modal-State in one turn, then Arithmetic + Argument in a second turn. Pass 2 is unchanged. Dependency-blocked sections are marked, never inferred, in every tier. 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, the authorial-direction thresholds of §5.1, and all namespace, firewall, and non-retrojection controls apply within the Unified Revision Pass exactly as they applied across the former sequential passes. ## 7. Begin with Pass 0 Only Before rewriting anything, produce only: 1. File Intake Sheet. 2. Risk rating. 3. Mechanical lint report (deterministic checks: number formatting, BC/AD format, operator form, calendar-state suffix preservation, slash-pair count, heading hierarchy, Machine Guard format, table framing, hyphenation, terminology substitutions). 4. Major active states, primary anchors, major operators. 5. Dependencies, including the State Vocabulary Register entries this file opens. 6. Likely problem areas. 7. Recommended section-level revision plan. 8. Audit notes requiring early author decision. 9. Recommended controlling exemplar(s): `File_00`, `File_02`, `File_51a`, `File_54`, or another named dependency. Use this intake form: ```markdown # 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: Controlling exemplar(s): ``` Do not revise the file during Pass 0. ## 8. Continuation Instruction After the Pass 0 intake is approved, use this instruction for Pass 1 and Pass 2: ```text Proceed with the next pass only. Use the previously revised version as the working base. Do not silently correct arithmetic. Do not alter anchors, modal states, node-classes, sign conventions, operators, or Mirror protocols unless the active layer explicitly requires clarification. Where uncertain, add an Audit note: or Dependency note:. Before asking for authorial direction, first think the issue through, recommend the best repository-compliant solution, and proceed under assumed authorial affirmation when the solution is high-probability and non-disruptive. Bring only genuinely doubtful issues to the consolidated Author-Decision list in Pass 2. ``` ## 9. Pass Deliverables Pass 1 returns: 1. Revised Markdown. 2. Audit notes. 3. Unresolved issues. 4. Recommended cross-file updates. 5. Updated Revision Log. Pass 2 returns: 1. Diff summary by change class, confirming every change is formatting, terminology, or an explicitly logged correction. 2. Arithmetic recheck report. 3. Consolidated Author-Decision list, recommendation first for each item. 4. Updated Revision Log. At the end of each response, clearly state what the next step should be. ## 10. Revision Log Form At the end of each pass, update this log: ```markdown ## Revision Log - File: - Revision date: - Style Guide version: - Restart Capsule version: - Passes completed: - Unresolved issues: - Author decisions made: - Authorial-direction handling: - Cross-file updates required: - Status: ``` Use `Authorial-direction handling` to record whether issues were resolved by assumed authorial affirmation, reserved for author decision, or marked as not understood / dependency blocked. ## 11. Layer Controls (applied within the Unified Revision Pass) The controls below are unchanged in content from v2.4; they now bind as simultaneous layer controls within Pass 1 rather than as separate passes. ### 11.1 Structural + Terminology layers Normalize heading hierarchy, section numbering, appendix placement, Markdown source structure, table framing, repository terms, number formatting, BC/AD format, hyphenation, and local file-reference style. Do not alter arithmetic, anchors, modal states, node-classes, sign conventions, operators, Mirror protocols, or theological claims. Apply high-probability formatting and terminology updates under assumed authorial affirmation. #### 11.1a File Map Control During the Structural layer, add a terse functional `File map` near the top of a repository file when it improves AI retrieval. The File map should identify what each major section does. Where useful, it may also name the active state, operator, or dependency status for that section. The File map is not a decorative table of contents. It should not repeat every heading mechanically, summarize the whole file in prose, or add rhetorical framing. Preferred placement: ```markdown ## 0. File-function ## 0.1 Working state register ## 0.2 File map ``` If a file has no working state register, place the File map immediately after `## 0. File-function`. Preferred compact form: ```markdown ## 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 | ``` For short files, the third column may be omitted. Machine Guard [FILE MAP RESTRAINT]: A File map exists for AI retrieval and structural navigation. It must remain terse, functional, and state-aware. Do not let it become a prose-heavy table of contents or duplicate the heading hierarchy. #### 11.1b Machine-Ingestion Check During the Structural layer, confirm that the file is structurally extractable for future AI use without being reshaped into a derived AI format. Check that: - the file header uses the required fields; - optional header fields are included only when useful; - the File map, if present, is compact and functional; - dense sections identify active state, operator, node-class, tradition, claim-status, or dependency where needed; - Machine Guards remain sparse and justified; - no heading, table, or note is shaped merely to imitate a future JSONL prompt-response pair. Canonical Markdown remains the source. JSON, JSONL, vector-index records, Knowledge Graph records, RAG metadata, and prompt/response training pairs are derived extraction layers. Machine Guard [CANONICAL MARKDOWN / DERIVED AI FORMATS]: Do not reshape a repository file into dialogue format, synthetic prompt-response format, JSONL format, or generic AI-summary format during ordinary file revision. Derived AI formats may be generated later from the Markdown source, but they must not replace or weaken the source file’s arithmetic, modal states, operators, node-classes, claim-status labels, or dependency boundaries. ### 11.2 Modal-State layer Audit modal states, node-classes, sign conventions, slash-pairs, ranges, display labels, calendar-state suffixes, blocks, envelopes, and Mirror protocols. Preserve simultaneous modal states unless the local file explicitly resolves them. Where `File_02` terminology is active, preserve the distinction between: - `MT Minimum-Regular`; - `MT Standard-Normal`; - cumulative Flood Week; - judgment-week envelope; - `Sumerian A / SKL Short`; - `Sumerian B / SKL Long`; - `+30 Apparent Mode`; - `+2 local rail`; - `+720 scale-state`. Where `File_22` / `File_51a` / rounded values are active or potentially confused, preserve the distinction between: - actual `9890` Cumulative-Regular Decimal Bridge; - rounded `9900` counterpart; - clean or mod-10 local-state display; - File_51a Rounded Scaffold state; - SKL rounded mod-10 Mirror display; - ordinary civil cross-axis span. Where `File_34` SKL / Berossus terminology is active, preserve the distinction between: - `486 BC` Berossus computational-anchor state; - `536 BC` biblical restoration anchor; - `539t/538n BC` fall-of-Babylon / Persian-transition field; - SKL base anchors `2906/2856 BC`; - SKL `+30` rail anchors `2936/2886 BC`; - SKL `+2` paired slash-displays such as `2938/2936`, `2908/2906`, `2888/2886`, and `2858/2856 BC`; - Cosmic Pixel `720 = 2 × 360`; - SKL-to-Berossus `2370` corridor; - `30 + 20 + 30` restoration corridor; - Nisan / Tishri phase-chain arithmetic; - Pillar / AD target state using civil cross-axis `BC + AD − 1`; - expansion difference / non-Residue state. Machine Guard [FILE_34 POST-FINAL CITATION CONTROL]: Do not import File_34's full SKL / Berossus derivation into a dependent file unless the local section explicitly opens that state. Route full Precessional Envelope, Sanctuary Fractal, Appendix B phase-chain, `2370` corridor, `30 + 20 + 30` corridor, and Pillar target machinery to `File_34 Final; post-final pressure tested` by dependency. ### 11.3 Arithmetic layer Check same-side spans, cross-axis spans, exact ratios, Key-of-23 conversions, exact halves, date ranges, envelope checks, Residue Protocol claims, and undefined operator dependencies. Do not silently repair arithmetic. If the correction is unambiguous and non-disruptive, recommend and apply only within the layer scope, then record the correction. If the correction would alter the file’s argument or state logic, mark it with an `Audit note:` and recommend the best solution. ### 11.4 Argument layer Separate arithmetic facts from interpretive claims. Clarify claim-status. Reduce rhetorical inflation. Move weak or exploratory material to notes or appendices where appropriate. Preserve theological, typological, symbolic, canonical, and reception-history material when it is textually anchored or needed to explain why a numeric structure matters. Label it rather than deleting it. ### 11.5 Author-Decision handling (within Pass 2) The consolidated Author-Decision list belongs to Pass 2. For each issue: 1. State the problem clearly. 2. State what is known from the file and control documents. 3. Give the best recommended decision. 4. Explain why that decision is preferred. 5. Identify what would change if the author chooses otherwise. Do not present undecided options without a recommendation unless the math or source logic is not understood. In that case, say what is not understood and what dependency is missing. ### 11.6 Finalization Perform Finalization only when the author explicitly says to mark the file Final. Finalization should: - restore or set `Status: Final` where appropriate; - remove temporary pass-language not intended for the source file; - retain necessary audit notes and dependency notes; - update the Revision Log; - list unresolved issues, if any; - list cross-file updates required, if any; - verify that any File map remains compact, functional, and source-relevant; - verify that machine-ingestion controls did not reshape the file into a derived AI format. After Finalization is completed, remind the author that a thorough Pressure Test remains available on request; the Pass 2 diff-audit does not replace a requested full pressure test. ## 12. Standard Return Format Use this return structure unless the author asks for another format: ```markdown # Pass [0 / 1 / 2 / Finalization] Result ## Revised Markdown [revised source text — Pass 1 only] ## Audit Notes [notes] ## Unresolved Issues [issues] ## Recommended Cross-File Updates [updates] ## Diff Summary and Arithmetic Recheck [Pass 2 only] ## Author-Decision List [Pass 2 only] ## Updated Revision Log [revision log] ## Next Step [state the next step] ``` For Pass 0, return the intake material only. ## 13. Dependency and Non-Inference Rule If a file depends on missing operators, undefined Prime constants, unavailable source rows, missing repository files, or a table not present in the current chat or control files, do not invent the missing structure. Use: ```markdown Dependency note: This section depends on [missing file/operator/constant/table]. Do not infer. Mark as dependency blocked until the prerequisite is supplied. ``` If the issue is not dependency-blocked but remains uncertain, use: ```markdown Audit note: This value / operator / state / claim appears uncertain because [specific reason]. Recommended handling: [best controlled recommendation]. Author decision required only if this recommendation is not accepted. ``` ## 14. Verification and Pressure-Test Boundary The Pass 2 Verification Pass (diff, change-class audit, arithmetic recheck) is part of every revision. A full pressure test remains separate and author-invoked: do not perform one unless explicitly requested, normally after Finalization, or earlier for a high-risk or foundational file at the author's request. When Finalization is complete, state: ```markdown Next step: a thorough Pressure Test of the Final file is available on request before publication. ``` ## 15. Closing Operational Rule The revision process must not make the repository smoother at the expense of precision. The working rule is: ```markdown Clarify the logic, preserve the terminology, reduce compression, add no ornament. ``` The working safeguard is: ```markdown Do not silently change arithmetic, anchors, modal states, node-classes, operators, sign conventions, or Mirror protocols. If a value appears wrong, mark it for audit unless the correction is mechanically required, high-probability, and non-disruptive; in that case, apply it under assumed authorial affirmation and record it. ``` ## 16. Vocabulary Registration and Change Archiving When a target file is finalized: 1. Register its new state vocabulary, convention updates, and Machine Guards in the `State_Vocabulary_Register`. 2. Append the Update Record verbatim to the `Repository_Change_Archive`. 3. Add at most a one-line status pointer to this file or the Style Guide. Do not absorb per-file vocabulary into either control file. Machine Guard [CONTROL-FILE NON-ACCRETION]: Per-file vocabulary, per-file Machine Guards, and historical Update Records do not accumulate in Project Procedures or the Style Guide. Route vocabulary to the Register and history to the Archive. The Archive is non-controlling. ## Revision Log - File: Project_Procedures - Revision date: June 10 2026 - Style Guide version: v2.5 - Restart Capsule version: v11.2 - Passes completed: Full control-file revision to v3.0 under Repository Revision Plan v3.0, Decisions 1–3, author-approved June 10 2026 - Unresolved issues: Restart Capsule appendix duplication with the State Vocabulary Register remains; recommended bounded Capsule v11.3 pointer update as next control-file action - Author decisions made: Adopted three-turn consolidated workflow with High-risk split; adopted mechanical lint in Pass 0 and diff-based Verification in Pass 2; routed per-file controls to State_Vocabulary_Register v1.0; archived historical Update Records to Repository_Change_Archive v1.0 - Authorial-direction handling: All changes applied under explicit author approval of Revision Plan v3.0 §9 Decisions 1–3. Governing Rules (§4), Authorial-Direction Protocol (§5), layer controls (§11), dependency rule (§13), and closing rules (§15) carried verbatim from v2.4. No target-file arithmetic, anchors, modal states, node-classes, sign conventions, operators, Mirror protocols, or theological claims were changed. - Cross-file updates required: Replace v2.4 Project Procedures and v2.4 Style Guide in the Project with v3.0 / v2.5; load State_Vocabulary_Register v1.0 alongside them in every revision chat; recommended Restart Capsule v11.3 pointer update; lint-only sweep of the 45 revised files once the lint script is validated - Status: Revised control file; v3.0 consolidated workflow active; diff-audited June 10 2026 ## 17. Context Economy (token-cost controls) Accuracy controls are primary; these rules cut cost without touching them. 1. **One chat per file.** Conversation history is re-sent with every message, so long chats grow quadratically expensive. Run Pass 0 → Pass 1 → Pass 2 → Finalization for one file in one chat, then start a new chat for the next file. The Project and these control files carry the continuity. 2. **Tiered loading.** Tier A (Style Guide, Procedures, Register, Restart Capsule, File_00) stays in project knowledge always. Tier B hub files stay in project knowledge for retrieval. Tier C files are attached only when the target file opens their states (named at Pass 0). Tier D files stay out of working projects entirely. The tier list is the File Cheat Sheet & Load Priority document. 3. **Effort setting.** Medium suffices for Pass 0 and Pass 2 (they are script-assisted and mechanical). Reserve High for Pass 1 on High/Critical-risk files. Avoid Max. 4. **Working papers stay out of project knowledge.** Lint reports, pass reports, diff audits, and the Revision Plan are deliverables, not controls; archive them outside the project. 5. **Scripts before prose.** Mechanical checks (lint, equation comparison, cross-file sweeps) run in the container at near-zero context cost; never perform them by re-reading files in conversation. ## Revision Log (v3.1 addendum) - Revision date: June 10 2026 - Change: §17 Context Economy added; no workflow, invariant, or control change - Basis: author cost constraints reported June 10 2026; Pilot 1 (File_46) experience ## 18. Novelty Verification Rule (added v3.2) Before any value, year-label, operator, state, or term in a target file is characterized as *new*, *absent from the repository*, or *unclear*, run an exhaustive exact-token search of the full text of the Restart Capsule and the State_Vocabulary_Register (and the Style Guide where the question is terminological) — a mechanical string search of the mounted control files, not semantic retrieval alone — covering the obvious variant forms: with and without `BC` / `AD`, slash-pair members, comma-grouped numerals, and repository abbreviations. A novelty or absence claim may be recorded only with that search performed and cited in the deliverable. If the token is found, the existing state controls: register the target file's usage as **convergence or conflict** with the named state, never as novelty. Semantic search may locate; only exhaustive token search may clear. Failure-mode note: this rule catches token collisions. It does not catch a concept present under a different name with no shared token; that residual risk remains covered by Pass 0 dependency work and Pass 2 verification. Precedent: the `1661 BC` correction of June 11 2026 — Pass 0 of File_38 declared the year-label a new anchor after consulting the Capsule through search excerpts and the header inventory; an exhaustive token search at control-file registration found it already capsule-governed in the body as the Baseline Entry / minimum state (Capsule v11.5; Register v1.4 §D.4; File_38 post-final citation-control update). Interpretive note: where this document or its companion controls cite a control file by version number, read the reference as the current edition of that control file unless the author directs otherwise. ## Revision Log (v3.2 addendum) - File: Project_Procedures - Revision date: June 11 2026 - Change: §18 Novelty Verification Rule added, with failure-mode note, precedent record, and current-edition interpretive note; header Status and Related files lines updated. No other section altered; all v3.1 content retained unchanged. - Authority: author-approved wording and author-directed bounded control-file update, June 11 2026. - Cross-file updates required: (1) Project knowledge — replace Procedures v3.1 with v3.2. (2) Project prompt — add the one-line echo supplied with this update. (3) Repository_Change_Archive — append the v3.1 → v3.2 record.