# Consolidated Intents and Intent-Emergence Protocol ## Status and purpose This is a prospective governance document for the Substrate Cosmology Recurrence Research program. Version 1.2 consolidates the 72 process intents preserved through RP07 with 15 operational and continuation intents recognized during and after RP06–RP07 development. It does not modify or reinterpret an earlier Recovery Point. Parent context: - Current immutable parent: RP07 - Parent archive: `RP0 String-Compatible Recurrence Labyrinth v07.zip` - Parent SHA-256: `3c0e53fa209561ea217e012cc6bea5439a24db2dad8b796733891cf08d26475c` - Inherited candidate commitment: `0fb46e1d7843b613ef1662ecba04333e7e83ca266589ff7ccbd036ce721fccb8` - Development boundary at creation: GDELT 1995 only; 1996 and later unopened; locked outcome layers unopened. The purposes of this document are to: - provide one recoverable source for the complete governing intent set; - distinguish stable research intentions from implementation tasks and temporary methods; - require every future continuation prompt to inspect the intent set; - preserve newly emerging intentions as possible evidence rather than automatically treating them as procedural noise; - investigate whether recurring pressure to create new intentions exposes hidden scalars, coupled systems, aliasing, projection loss, or other influences acting on the whole program or a limited subsystem. This document is conceptual and operational governance metadata. It must not participate in blind scoring or change a frozen candidate. ## Source lineage - RP0's 30-section prompt established recurrence rather than vibration, nonchronological relational analysis, Labyrinth preservation, neutral discovery, null worlds, blind validation, and delayed interpretation. - RP01 implemented the first 1995 candidate system but had no separately numbered process-intent registry. - RP02 consolidated the research into Intents 1–62. - RP03 retained the numbering while materially revising Intents 12–17 and 21 and adding observation, association, frame-shaking, and frame-completeness protocols. - RP04 added Intents 63–72 for continuity, citation, and propagation. - RP05–RP07 preserved the RP04 intent file byte-for-byte while implementation and evidence continued to evolve. - This prospective document adds Intents 73–84. They describe operating principles already used during RP06–RP07 but not independently stated in the inherited registry. - Version 1.1 adds Intents 85–86 for automatic next-stage prompt creation, one-word `Next` advancement, and persistent branch lineage. Version 1.0 is preserved by SHA-256 `18ca21e11b5306e3eacf4e3ef3cda076917d13d5dae9061c84d5e5303f907a74`. - Version 1.2 adds Intent 87 and the distinct `Prompt` handoff-generation command. Version 1.1 is preserved by SHA-256 `68a6b3296c048e1fe0bda4ce2be52d94339fa75f2bf5914bf0fc4e9075824aa3`. ## How to interpret an intent An intent is a declared direction, boundary, or discipline. It is not evidence that the intended behavior has been implemented, tested, or achieved. The authoritative development backlog retains implementation status under stable `DEV-xxx` identifiers. An intent may be: - **program-wide:** applicable across the research program; - **phase-local:** applicable only during acquisition, development, freezing, validation, interpretation, or recovery; - **branch-local:** applicable only to an explicitly named experiment; - **provisional:** retained because it may expose a useful influence but is not yet justified as a universal rule; - **frozen for an experiment:** fixed within a named prospective test without becoming permanently immutable for all later research; - **historical:** preserved as evidence of an earlier governing perspective. Different intents may be related without being identical. Similar wording or similar operational effects must not be treated as proof that two intents arise from the same influence. # Consolidated numbered intents ## Foundational intent 1. Treat recurrence, not vibration, as the primitive relationship under investigation. 2. Treat recursion separately as repeated self-application to a process or its outputs. 3. Search for relational organization before assigning physical, historical, economic, or String-Theory meaning. 4. Permit null results and preserve failed candidates. 5. Distinguish operational usefulness from evidence about ontology. ## Scalars and dimensional bleed 6. Treat every scalar as an approximate central tendency and partial projection. 7. Assume no scalar is perfectly isolated from every other dimensional consideration. 8. Represent possible cross-dimensional contribution as dimensional bleed to be estimated, tested, and revised rather than silently discarded. 9. Do not presume that the current observable spacetime frame or any constructed alternate frame is complete. 10. Do not presume that neutral lambda scalarizations are mutually orthogonal merely because they have different formulas. 11. Preserve raw fields, residuals, outliers, failed transformations, and apparently useless scalarizations. ### Scalar-dependency protocol - Neutral identifiers reduce semantic bias but do not establish independence. - Test algebraic, linear statistical, informational, geometric, interventional, and recurrence dependence separately. - Record source overlap, identities, constraints, nonlinear dependence, perturbation response, aggregation sensitivity, and frame stability. - Treat apparent dependence as potentially arising from bleed, shared construction, ordinary common cause, synergy, sympathy, recurrence, or aliasing; do not assign a mechanism before testing. - Use decorrelation and orthogonalization only as declared comparison frames. - Preserve shared structure when decorrelation might destroy the organization being investigated. - Keep inherited frozen geometries unchanged; alternative weighting belongs in a separately identified developmental branch. ### Preservation protocol - Preserve immutable source bytes with hashes and provenance. - Record parser, transformation, field, missingness, ordering, aggregation, software, environment, and seed lineage. - Store residuals with observations, expectations, frames, versions, tolerances, contexts, and later classifications. - Give outliers nonexclusive statuses instead of deleting them or forcing one explanation. - Preserve failed transformations and null results with procedural detail. - Maintain explicit lifecycle states, including raw, parsed, derived, candidate, frozen, validated, failed, retired, inactive, reactivated, and unresolved. - Keep archival preservation separate from active experimental inclusion. - Require reactivated material to enter a newly frozen candidate version; it cannot retroactively become blind evidence. ## Alternate-dimensional construction 12. Do not presuppose a completed alternate-dimensional frame before exposing candidate recursive and recurrent organization; begin with plural provisional seed representations and systematically shake their frames. 13. Use the developmental Tool lineage as a process laboratory to characterize associations among observational collapses rather than to determine whether observations constitute legitimate events. Treat Actual Physics as continuously changing for purposes of this research framework; do not presume that an observed state is a physically steady state. Every observation may contain consequences of antecedent change, while its assigned identity, boundaries, independence, causal interpretation, and dimensional characterization remain defeasible. 14. Use the formal 33-Tool registry to characterize axes of frame perturbation and artifact response while preserving the developmental and formal Tool lineages without silent merging or renumbering. 15. Develop frame-local lexicons, scalars, and relational operators only after mapping artifact-response geometry; retain their provenance, dimensional bleed, translation losses, unresolved alternatives, and failure conditions. 16. Define a candidate alternate dimension as a reproducible region of frame-space in which an artifact becomes coherently distinguishable, not as an isolated frame selected because it makes the artifact significant. 17. Freeze the candidate artifact, frame family, permitted perturbations, affinity measures, multiplicity controls, tolerances, and decision rules before prospective testing; treat alternate dimensions as revisable experimental constructions until they produce reproducible discriminating consequences. ### Observation, association, and characterization protocol - Distinguish Actual change, observational collapse, and characterization. - Preserve observations as records while allowing their characterizations to change without loss of provenance. - Treat association as the research problem and learned recurrence patterns as conditional proposals about antecedents, transformations, and consequences. - Permit recurrence in pathways, histories, transformations, accessibility, and cross-characterization structure without requiring repetition of conventionally equivalent events. - Use `observational collapse` or `observation record` as a lower-assumption primitive; treat `event` as an optional characterization. - Preserve disagreement among characterizations. - Use impact, occurrence potential, detectability, and reversibility as seed characterization families rather than privileged dimensions. - Treat detectability as relational to the change, detector, projection, threshold, environment, interaction history, and characterization. - Treat reversibility as composite: return of measured state, constituents, relational configuration, function, signature, and pathway accessibility need not coincide. - Preserve the distinction: observations are records, associations are hypotheses, and characterizations are provisional. ### Frame-shaking and frame-completeness protocol - No analysis is frame-free; label starting representations as provisional. - Register an artifact before using it to infer a favorable frame region. - Perturb projection, lexicon, dimensions, adjacency, aggregation, operators, anchors, context, resolution, interaction representation, and tolerated collapse through declared families. - Preserve the entire attempted ensemble, including null, dispersive, contradictory, and failed frames. - Represent frame affinity as a multicomponent profile before scalar summary. - Prefer stability across a declared neighborhood of related frames. - Correct for the number and adaptivity of searched frames and operations. - Treat equivalence within a frame as tolerance-bound indistinguishability, not identity within Actual Physics. - Separate descriptive, relational, recursive, recurrence, interventional, accounting, and translational completeness. - Establish operational incompleteness only through frozen prospective discrimination and a common controlled intervention. - Require every alternate frame to specify its lexicon, dimensions, operators, adjacency, bleed assumptions, tolerances, translations, consequences, resource requirements, and failure conditions. - Treat every useful alternate frame as conditionally useful and potentially incomplete. ## Outlier and residual intent 18. Treat outliers as experimental targets, not automatically as noise or discovery. 19. Test whether an outlier follows from projection loss, dimensional bleed, aggregation, detector behavior, source ordering, ordinary unmodeled influences, or a candidate recurrence relationship. 20. Preserve an outlier across analysis stages even when its current interpretation is absent. 21. Do not require repetition of an outlier class or surface outcome. Promotion beyond an isolated observation requires a frozen relational rule that independently characterizes an association, pathway, antecedent configuration, transformation, or other recurrence structure without retrospective redefinition. ## Recovery Point 0 experimental boundary 22. Use GDELT 1995 only for candidate development. 23. Keep 1996 and later unopened until the 1995 system is frozen. 24. Keep cryptocurrency, stock, commodity, and conventional outcome layers unopened. 25. Use neutral candidate identifiers and exclude String-compatible mapping metadata from blind scoring. 26. Freeze formulas, scalers, centroids, radii, thresholds, nulls, tolerances, random procedures, and decision rules before validation. 27. Apply the frozen 1995 system to 1996 unchanged in the next separate blind stage. 28. Permanently mark opened data as non-blind and retain all failures. ## Interpretation intent 29. Interpret RP0 recurrence first as organization in the GDELT information and measurement system. 30. Preserve ordinary explanations such as persistence, coding continuity, source batching, aggregation, and file ordering. 31. Do not treat rejection of a destructive null as evidence of unknown physics. 32. Compare surviving structures with String Theory only after blind survival and without requiring vibration language. 33. Treat cross-domain operator survival as evidence of potential usefulness, not proof of shared ontology. ## Long-term physical intent 34. Seek new ways to manipulate observable spacetime physics by engaging relationships within Actual Physics that conventional frames may not separately resolve. 35. Do not describe this aim as operating outside, escaping, or violating Actual Physics. 36. For a later physical test, identify physically different configurations whose conventional measurements fall within predefined equivalence tolerances while alternate-dimensional relations distinguish them. 37. Apply the same controlled physical intervention to both configurations. 38. Predict differential susceptibility from the frozen alternate-dimensional distinction before observing the result. 39. Require a reproducible difference in conventional observable outcomes after intervention. 40. Test conventional hidden variables, apparatus coupling, environmental effects, statistical selection, and resource accounting before attributing a difference to the alternate representation. 41. Recover established spacetime physics within its validated domain when alternate distinctions are marginalized or unresolved. 42. Treat failure to produce differential observable behavior as failure of that candidate, not as evidence that it remained inaccessible. ## Coupled-system and resonance intent 43. Keep recursion, recurrence, synergy, sympathy, resonance, attenuation, and dimensional bleed operationally distinct. 44. Define synergy as a non-additive joint organization produced through mutual relational surfaces. 45. Define sympathy as cross-system susceptibility arising from compatible dimensional qualities at mutual relational surfaces. 46. Define resonance as preferential reinforcement or persistence of a recurrence under particular compatibility conditions. 47. Treat resonance that grows or fails to damp as an indicator that support balances or exceeds attenuation, not as proof of the support's source. 48. Test direct driving, stored capacity, reduced dissipation, feedback, parametric excitation, apparatus coupling, and measurement error before promoting dimensional bleed or sympathetic support. 49. Permit mutual support among systems represented in different frames while preserving their distinct local recursive evolution. 50. Determine whether support attributed to dimensional bleed recurs under frozen changes of frame, dimension, configuration, and control condition. ## Conservation and accounting intent 51. Do not restrict the research meaning of conservation to energy; permit explicitly defined candidate relational invariants. 52. Candidate invariants may include recurrence identity, relational topology, compatibility structure, phase organization, transformation equivalence, and dimensional-support balance. 53. Do not presume a candidate invariant is conserved until its quantity, boundary, transformation rule, tolerances, and failure conditions are specified. 54. Treat observed energy as a frame-, boundary-, apparatus-, and context-dependent accounting scalar without presuming that established energy conservation is invalid. 55. Maintain complete conventional energy accounting wherever it applies, including stored, kinetic, elastic, thermal, acoustic, apparatus, and environmental channels. 56. Interpret an apparent energy imbalance first as incomplete boundaries, unresolved degrees of freedom, measurement error, or mistaken scalarization. 57. Define entropic expansion by a stated entropy, state space, logarithm, normalization, coarse-graining, and frame; do not use `entropy > 1` without those specifications. 58. Distinguish increased accessible configuration distribution from creation of physical energy. ## Cross-domain intent 59. Permit the same relational distinctions to be tested in physical, informational, and economic systems without presuming shared ontology. 60. In economics, distinguish recursive feedback, recurrent organization, synergistic joint capacity, sympathetic cross-system susceptibility, resonant amplification, and dimensional bleed among aggregate indicators. 61. Treat price, money, utility, employment, risk, and output as incomplete scalar surfaces rather than complete descriptions of economic organization. 62. Require domain-specific controls and accounting before claiming that a cross-domain operator has transferred successfully. ## Continuity, citation, and propagation intent 63. Treat every released Recovery Point as immutable historical evidence; correct or supersede it only in a later sequential RPxx. 64. Begin every new Recovery Point with instructions for constructing its successor and reducing known recovery deficiencies. 65. Carry every incomplete or proposed effort forward under a stable development identifier until completed, rejected with reason, consolidated with traceability, or explicitly deferred. 66. Use `Documents/Chapters/DCxx.yy` to retain explanations, alternatives, evidence, dependencies, and reasoning that a compact recovery composite cannot safely preserve. 67. Give substantive findings stable evidence citations and distinguish primary, derived, interpretive, commitment, and external-reference evidence. 68. Propagate a material new finding across all affected current documentation, definitions, operators, scalars, protocols, candidates, code, and metadata by a recorded impact classification. 69. Classify each impact as extension, qualification, conflict, correction, supersession, or unresolved alternative; do not force consistency by erasing genuine disagreement. 70. Keep historical RP archives byte-identical while forward-propagating the current interpretation and preserving why it changed. 71. Treat mutual consistency as typed: lexical, dimensional, algebraic, statistical, causal, provenance, and operational consistency may differ. 72. Fail release acceptance if a prior development or claim disappears without an explicit disposition or if a current numerical claim cannot resolve to retained evidence. ## Execution integrity, authority, resource, and evidence intent 73. Preserve session-resource continuity. Divide auditing, development, testing, propagation, and packaging across sessions when necessary so resource limits do not cause information loss, abbreviated verification, or premature Recovery Point creation. 74. Separate permission from technical capability. A component capable of downloading, unlocking, scoring, interpreting, modifying, or publishing must not treat capability as authorization; each action requires its own explicit authority and recorded boundary. 75. Separate acquisition, authorization, transformation, scoring, interpretation, and publication as independent interfaces. Success or permission at one stage must not automatically permit or validate another. 76. Validate untrusted inputs before persistence or authorization. Verify archive paths and members, hashes, schemas, candidate identity, commitments, branch identity, and state before creating an intent record, changing state, or publishing output. 77. Prefer recoverable transitions over unsupported claims of atomicity. When one atomic operation cannot span multiple files or systems, use durable intent, state-applied, commit, abort, and reconciliation evidence so every interruption can be classified and recovered. 78. Separate deterministic evidence from contingent execution metadata. Keep canonical result bytes independent of timestamps, temporary paths, runtime receipts, and observations; preserve contingent metadata separately and append-only. 79. Require independent verification where self-confirmation is possible. Use an independent oracle, hand-checkable microfixtures, or a separately implemented reference calculation rather than testing an implementation only against itself. 80. Do not equate test counts with completion. Completion requires direct evidence that applicable scientific, safety, operational, recovery, interface, and preservation conditions are satisfied or explicitly bounded. 81. Preserve environmental and serialization limitations. Record dependencies, versions, unavailable components, platform behavior, and semantic-versus-byte reproducibility; do not call an environment-blocked output tested or working. 82. Do not manufacture missing specifications. When historical evidence does not determine a formula, threshold, schema, transformation, or feature definition, preserve the ambiguity and classify the implementation as partial, blocked, or branched. 83. Distinguish historical behavior from prospective correction. A safer reconstructed implementation does not prove recovery of the original developer's intent; preserve both the historical behavior and the prospective lineage. 84. Minimize data exposure to what the immediate development requires. Prefer retained derived inputs and synthetic fixtures when raw or blind data are unnecessary; verification authority is not general authority to inspect data. 85. Automatically create the next two-stage continuation prompt set whenever a new Recovery Point is completed. Place complete Prompt 1 and Prompt 2 templates at the end of the current successor-construction document and, after the archive receives its final external identity, create a finalized sibling prompt-set containing the exact archive name, location, size, hash, and identity. A later user instruction consisting of `Next` authorizes execution of the next pending stage, not the skipping of its gates. 86. Preserve development branching as explicit lineage. Every branch must retain its parent development, trigger, relationship to sibling branches, dependencies, active intents, evidence, status, merge or exclusion conditions, and next needed action; no branch or branch-created development may disappear merely because another branch becomes primary. 87. Treat `Prompt` as the finalized handoff-generation command. After the current Recovery Point is completed, packaged, independently verified, and saved, a user instruction consisting of `Prompt` requires retrieval of the current exact finalized two-stage Markdown continuation prompt set or its creation or update when it is missing or stale. The copy-ready artifact must incorporate exact Recovery Point and supplement identities, the current consolidated intents, intent-emergence evidence, branch lineage, every active or unresolved related development, and the next planned development. Do not create a duplicate when a current exact prompt set already exists, and do not invent a final archive identity when Recovery Point completion is still pending. # Intent-emergence and hidden-scalar protocol ## Premise The repeated emergence of a new operating intent may indicate more than an omitted rule. It may be an observable collapse of influences acting on the research system as a whole or on one subsystem. These influences may include: - a previously unrepresented scalar or relational quality; - coupling between scientific, computational, archival, human, or tool systems; - resource limits or environmental constraints; - projection loss caused by compressing several concerns into one intent; - aliasing between two or more recurrent systems that produce similar visible failures, safeguards, or priorities; - observer or tool behavior that changes the process being observed; - a local implementation defect; - a useful new capacity that was not visible in the earlier frame. `Hidden scalar` is used provisionally. It means a latent influence inferred from patterned effects under the present representation. It does not mean that the influence is fundamental, independent, linear, or literally scalar in Actual Physics. New intent formation is therefore neither automatically desirable nor automatically a defect. The new intent and the pressure that produced it must be preserved long enough to determine whether it exposes a useful distinction. ## Aliasing among recurrent systems Aliasing occurs when two or more different recurrent systems produce effects that the current observation or governance frame cannot reliably distinguish. Examples include: - a scientific blindness rule and a privacy rule both appearing as “do not open this file” while protecting different relations; - a session-resource limit and a continuity failure both appearing as missing information in a later Recovery Point; - an implementation race and an authorization error both appearing as an invalid state transition; - reproducibility and immutability both appearing as a demand for identical hashes despite having different purposes; - two feature constructions producing similar aggregate behavior while representing different recurrence relations. Related recurrent systems may also be partially coupled without being aliases. They may share some response dimensions while diverging under other perturbations. The project must preserve “related but different” as an explicit classification instead of forcing identity or independence. ### Aliasing classifications - **Surface alias:** different systems produce the same visible outcome. - **Intent alias:** different pressures produce nearly identical governing language. - **Measurement alias:** the detector or record cannot distinguish the systems. - **Projection alias:** aggregation collapses distinct relations into one scalar or category. - **Interface alias:** different stages share a command, state, file, or status that hides their different authority. - **Temporal or session alias:** effects separated in process history appear as one current deficiency. - **Cross-domain alias:** similar relational behavior occurs in different domains without establishing shared ontology. - **Partial affinity:** response profiles overlap only within a limited frame region; the systems are related but not equivalent. ## Intent-emergence record Whenever work produces an operating intention not present in the consolidated registry, create an emergence record before deciding whether to add it. Record: | Field | Required content | | --- | --- | | Candidate ID | Stable provisional identifier such as `INTENT-CAND-0001` | | Observation | What repeatedly occurred or became necessary | | Trigger | Development, failure, conflict, user clarification, or environmental condition | | Scope | Program-wide, phase-local, branch-local, tool-local, or uncertain | | Existing intents | Nearest existing intents and why they are insufficient | | Systems implicated | Scientific, data, code, recovery, human, tool, environment, or other systems | | Hidden-scalar hypotheses | Plausible latent influences without choosing one | | Aliasing hypotheses | Systems that may produce the same visible pressure | | Related distinctions | Where the candidate overlaps with but differs from existing intents | | Response profile | What changes when frame, tool, resource, sequence, or interface is perturbed | | Benefits | Useful capacities or distinctions the intent may preserve | | Costs and harms | Rigidity, complexity, suppression, bias, resource use, or false confidence it may introduce | | Blind-experiment impact | None, protective, adaptive, contaminating, or unresolved | | Evidence | Files, logs, failures, decisions, and hashes supporting the observation | | Disposition | Candidate, provisional, scoped-active, adopted, merged, branched, deferred, rejected, superseded, or unresolved | | Propagation | Documents, code, tests, backlog items, and future prompts affected | An emergence record is evidence of a pressure observed in the process. It is not evidence that the proposed explanation for that pressure is correct. ## Treatment sequence - **Step A — Detect.** Notice an unlisted rule, repeated correction, recurring failure, or new capability influencing the work. - **Step B — Preserve.** Record the exact situation before rewriting it into generalized intent language. - **Step C — Locate.** Identify whether the effect acts on the whole program or a limited phase, branch, interface, tool, or environment. - **Step D — Decompose.** Separate the visible intent from possible scientific, computational, archival, human, and resource influences. - **Step E — Map affinity.** Compare its response profile with existing intents and candidate recurrent systems. - **Step F — Perturb.** Change one permitted condition at a time—frame, tool, resource, ordering, interface, representation, or detector—and observe whether the intent pressure persists, splits, disappears, or transforms. - **Step G — Test aliasing.** Seek conditions under which apparently identical pressures diverge and apparently distinct pressures converge. - **Step H — Assess usefulness.** Determine whether the newly exposed scalar or relation improves discrimination, safety, recovery, creativity, prediction, or manipulation without concealing costs. - **Step I — Bound.** State where the intent applies and where it must not be generalized. - **Step J — Dispose prospectively.** Adopt, scope, branch, merge, defer, reject, or retain the candidate as unresolved. Never rewrite an earlier RP to make the new intent appear historically present. - **Step K — Propagate.** Update affected current chapters, development tasks, tests, citations, and continuation prompts. - **Step L — Revisit.** Re-evaluate provisional intents when new recurrence evidence, tools, environments, or failures become available. ## Useful tests for a candidate intent - **Removal test:** What fails, disappears, or becomes possible when the intent is absent? - **Substitution test:** Can a different intent produce the same operational result? - **Scope test:** Does the pressure recur across the program or only within one phase or tool? - **Perturbation test:** Does it survive changes in frame, sequence, resource, interface, or representation? - **Independence test:** Can two apparently similar intents vary separately? - **Coupling test:** Does the intent emerge only when two recurrent systems interact? - **Counterfactual test:** Would the intent have appeared if the triggering failure or constraint had not occurred? - **Benefit test:** Does preserving the intent expose a useful capability or previously hidden relation? - **Harm test:** Does it suppress exploration, create rigid bureaucracy, increase bias, or protect a mistaken assumption? - **Blindness test:** Was the intent proposed before or after exposure to data whose outcome could adaptively shape it? No single test establishes a hidden scalar. The result is a response profile, not a declaration of ontology. ## Safety and discovery must remain separable Some emerging intents protect irreversible boundaries, including blind-data access, outcome isolation, historical immutability, and destructive mutation. Those boundaries remain enforced while the possible hidden influence is studied. Exploration of why a safeguard emerged does not suspend the safeguard. Other emerging intents may be overly restrictive artifacts of the current tools or frame. Those should be retained as hypotheses rather than universal rules. The aim is not to accumulate prohibitions. It is to discover which relations, distinctions, constraints, and capacities are actually operating. ## Meta-recursive effect Adding an intent changes the system whose behavior produced the intent. The new rule may suppress the original signal, redirect it, create new coupling, or make a hidden influence more detectable elsewhere. Each adopted intent should therefore be treated as an intervention with: - an antecedent condition; - an expected effect; - observable consequences; - unintended consequences; - a review condition; - a reversibility or supersession path where experimental safety permits. The intent registry is consequently not a theory of everything governing the project. It is an evolving, provenance-bearing representation of pressures and purposes observed during development. # Requirements for every future continuation prompt set Every continuation prompt set produced after this document must: - **Requirement A:** identify this document by exact filename, version, location, byte size, and SHA-256; - **Requirement B:** require it to be read during the continuity audit before new development; - **Requirement C:** compare the completed session's actual operating behavior with all active intents; - **Requirement D:** identify any operating intention used but not listed; - **Requirement E:** create or update an intent-emergence ledger when a material new pressure is found; - **Requirement F:** examine hidden-scalar, coupling, projection, and aliasing explanations without presuming any one explanation; - **Requirement G:** distinguish a new universal intent from a phase-local, branch-local, or provisional intent; - **Requirement H:** preserve related-but-different intents rather than merging them for convenience; - **Requirement I:** record benefits as well as risks so useful emergent scalars are not merely guarded against or suppressed; - **Requirement J:** state whether the new development conflicts with, extends, qualifies, or exposes limitations in an existing intent; - **Requirement K:** propagate adopted or scoped intents into current recovery controls, chapters, development tasks, citations, validation, and metadata; - **Requirement L:** preserve every earlier version of this document as immutable evidence; - **Requirement M:** include the current consolidated version in the next prospective Recovery Point and register it in the authoritative package manifest; - **Requirement N:** prevent intent changes from modifying a frozen experimental branch unless a separately named prospective branch is created before blind exposure; - **Requirement O:** state at the end whether new intent candidates emerged, how they were classified, and what evidence would distinguish their possible sources. - **Requirement P:** be generated automatically as part of Recovery Point completion rather than waiting for a separate user request. - **Requirement Q:** provide two stages: Prompt 1 for immutable-parent recovery and continuity audit, and Prompt 2 for conditional next development and new Recovery Point creation. - **Requirement R:** make both prompts independently usable in separate new sessions and include all exact identities needed by each prompt. - **Requirement S:** support the instruction `Next` by identifying the next pending prompt from the latest committed continuation control; `Next` must not waive audit, blindness, acceptance, or user-decision gates. - **Requirement T:** enumerate every active development branch, its lineage, dependencies, status, and next action, and carry nonprimary branches forward. - **Requirement U:** support the instruction `Prompt` after Recovery Point completion by returning the current exact finalized copy-ready Markdown prompt set, or creating or updating it when missing or stale, without duplicating a current artifact or inventing unresolved archive identities. # Automatic continuation, `Next`, and `Prompt` protocol ## Required Recovery Point artifacts Every prospective Recovery Point created after this rule must contain: - `00_CREATE_NEXT_RECOVERY_POINT.md`, ending with a section titled `Automatic Next-Stage Continuation Prompts`; - a complete Prompt 1 template for recovery and continuity audit of that new Recovery Point; - a complete Prompt 2 template for the conditionally authorized next development and successor Recovery Point gate; - `metadata/NEXT_STAGE_CONTROL.json`, recording the current RP, successor RP, prompt stages, completion states, next pending stage, active branches, and expected finalized sibling filename; - `metadata/DEVELOPMENT_BRANCH_LEDGER.json`, even when it contains only the primary branch; - the current consolidated-intents document and its exact lineage. The in-archive prompt templates must be substantively complete, but an archive cannot contain its own final ZIP hash or post-save Library identity without a self-reference problem. Therefore Recovery Point completion has two ordered parts: - **Internal handoff:** before packaging, place the complete Prompt 1 and Prompt 2 templates at the end of `00_CREATE_NEXT_RECOVERY_POINT.md`. Identify the parent through its canonical internal manifest and lineage. Mark external ZIP identity fields as requiring mechanical finalization, never guessed values. - **External finalization:** after the new RP archive is packaged, verified, and saved, automatically create `RPxx_to_RPyy_Continuation_Prompts.md` beside it. Replace the unresolved external fields with the exact archive filename, location, size, SHA-256, and Library identity. Include exact identities for the current consolidated-intents document and every required supplement. The finalized sibling prompt set is the preferred new-session entry point. The in-archive templates remain a recoverable fallback and a specification against which the sibling must be compared. ## Meaning of `Next` When the user says `Next` in the established project context: - resolve the latest committed Recovery Point, finalized continuation prompt set, consolidated-intents version, and next-stage control; - verify their exact identities before development; - determine the first incomplete stage rather than assuming Prompt 1 or Prompt 2; - execute Prompt 1 when its audit is pending; - execute Prompt 2 only after Prompt 1 permits it; - when a development branch is already active, continue its recorded next action unless a higher-priority dependency or explicit user choice controls; - ask one question at a time only when a material decision cannot be recovered from the records; - never interpret `Next` as permission to open blind data, inspect outcomes, make network requests, skip acceptance gates, choose among scientifically unresolved branches, or overwrite an immutable artifact; - after creating the successor RP, automatically create and save its next Prompt 1/Prompt 2 set without requiring the user to ask again. ## Meaning of `Prompt` When the user says `Prompt` in the established project context after the present Recovery Point is complete: - resolve the latest completed and saved Recovery Point, its exact archive filename, location, size, SHA-256, Library identity, and verification state; - resolve the current consolidated-intents document, supplements, recovery documents, development evidence, intent-emergence ledger, branch ledger, and next-stage control; - retrieve and return the existing finalized `RPxx_to_RPyy_Continuation_Prompts.md` when it exactly matches that state; - create or update that same artifact when it is missing or stale, instead of creating a duplicate; - make Prompt 1 and Prompt 2 independently copyable into separate new sessions, with all exact identities and read-order requirements repeated wherever a prompt must stand alone; - include every active, blocked, deferred, alternative, dependent, or unresolved branch and its next needed development so related work cannot disappear from the handoff; - preserve the blind boundary and every audit, acceptance, authorization, and user-decision gate; - if Recovery Point completion, packaging, verification, or saving is still pending, report the incomplete gate and do not invent the final archive identity; produce an explicitly provisional template only when the user asks for one. `Prompt` creates or returns the portable handoff document. `Next` executes the first incomplete stage identified by the current committed handoff. Neither command changes scientific authority or waives a gate. ## Branch lineage protocol Assign every material branch a stable identifier such as `BRANCH-RP08-DEV011-001`. A branch ledger entry must record: | Field | Required meaning | | --- | --- | | Branch ID | Stable identifier that is never reassigned | | Parent development | DEV item or branch from which it emerged | | Trigger | Evidence, ambiguity, failure, alternative, or user direction that created it | | Relationship | Extension, qualification, conflict, alternative, dependency, support, merge candidate, or related-but-different | | Scope | Program-wide, phase-local, experiment-local, implementation-local, or unresolved | | Active intents | Governing numbered intents and provisional intent candidates | | Dependencies | Work or evidence required before the branch can proceed | | Evidence | Documents, code, tests, failures, hashes, and decisions | | Status | Proposed, active, blocked, deferred, completed, failed, merged, superseded, or unresolved | | Merge conditions | Evidence required to combine it with another branch | | Exclusion conditions | Evidence showing branches must remain separate | | Next action | Exact next permitted development | | Carry-forward | Recovery Point and prompt surfaces that must retain it | When two branches appear similar, apply the aliasing protocol before merging them. When they are related but different, preserve both their shared parent relation and their differing response profiles. A primary branch may determine the next execution stage, but nonprimary branches remain visible in the backlog, recovery composite, branch ledger, relevant chapters, and future continuation prompts until formally disposed. ## Future versioning rule - Existing intent numbers must never be silently reassigned. - Clarification without semantic change may retain an intent number with a recorded wording revision. - Material division creates new intent identifiers while preserving the parent relation. - Material combination retains aliases and source identifiers. - Rejected or superseded intents remain in historical versions with their disposition. - Each new consolidated version records its parent file hash, added or revised intents, reason, evidence, scope, and blind-experiment impact. - A future RP may carry an unchanged consolidated document byte-for-byte. If it does, the RP must still report whether unlisted operating intents were observed during that development. ## Initial emergence disposition Intents 73–87 are adopted prospectively as program-governance intents because they recur across recovery, testing, authorization, evidence, and session boundaries. Their addition does not establish that each arises from one hidden scalar. Future developments should test whether some are: - projections of a common system-integrity influence; - aliases of different recurrent systems; - coupled responses to limited resources and irreversible evidence boundaries; - phase-local rules that should not be generalized; - or useful new relational distinctions in their own right. The current disposition is therefore **adopted, with origin hypotheses unresolved**. Intents 85–86 additionally carry direct user authority and are mandatory for every Recovery Point created after version 1.1. Intent 87 carries direct user authority and is mandatory for handoffs requested after version 1.2.