# Decision ledger ## D-001 — Evergreen identity - Decision: Use **App Store Forecast** as the working identity and `appstoreforecast` as the repository name; keep 2031 as an edition target. - Reason: A year in the brand would prevent later forecast editions. - Rejected: `Chart 31`, `AppStore31`. - Status: Superseded for the public identity by D-015. The repository name is retained as an internal compatibility path. ## D-002 — Inventory depth - Decision: Exactly ten ranked apps per research-derived category. - Reason: Fewer, better-supported forecasts are more educational and easier to refresh than twenty thin entries. - Rejected: Top 20 per category. ## D-003 — Storage - Decision: Use version-controlled static data for the first release. - Reason: 230 forecast records plus sources and relationships do not justify a database; static editions improve inspectability and history. - Revisit when: Public submissions, accounts, voting, saved forecasts, or a multi-author editorial workflow is authorised. ## D-004 — Geographic evidence - Decision: Use a transparent global composite with explicit regional lenses. - Reason: Consumer-app futures will be shaped by different policy, energy, hardware, payment, cultural, and platform conditions across leading markets. - Rejected: Treating UK policy or one national storefront as globally representative. ## D-005 — Public process - Decision: Publish material sources considered, including rejected and contradictory research, plus prompts, concise critic verdicts, limitations, and edition diffs. - Reason: The research process is a first-class educational output and the primary basis for AI credibility. ## D-006 — Forecast surface - Decision: Forecast Top Free iPhone category charts averaged across July 2031. - Reason: Free, paid and revenue charts measure different things; public Apple surfaces do not expose a defensible global grossing chart or download totals. - Rejected: Mixing free, paid and grossing rankings; one-day 31 July snapshot. ## D-007 — Global display - Decision: Use a 12-lens coverage-balanced consensus built from 27 named storefronts, with countries equal inside each lens and lenses equal globally. - Reason: This is transparent and does not pretend to know global downloads or revenue. Regional results remain inspectable. - Rejected: Calling the result an Apple global chart; silently weighting by market size without dated installed-base evidence. ## D-008 — Research-derived taxonomy - Decision: Publish 23 primary forecast categories and five watchlist candidates; keep Kids as a special surface. - Reason: The 0.50 cross-market coverage gate, distinct-discovery test and ten-archetype capacity test produced that result after every current category was accounted for. - Rejected: Forcing the early estimate of about 15 categories. ## D-009 — Backtest claim - Decision: Publish **improvement not demonstrated**. - Reason: The available 2021 and 2026 chart record does not satisfy the preregistered monthly/daily data gate, despite a favourable exploratory proxy. - Rejected: Presenting the proxy result as validated forecasting skill. ## D-010 — Distribution boundary - Decision: Build and prove the local static site, but do not deploy it or register/configure `appstoreforecast.com` in this scope. - Reason: The Gauntlet approval covered research and build, not public release or an external domain action. ## D-011 — Probability-blind category calibration - Decision: Author all 27 storefront category-existence probabilities from packets that omit previous probabilities, coverage scores, ranks and model output; integrate only after all independent records pass. - Reason: Explanations generated around already selected values are not independent forecasts and create false confidence. - Empty-evidence rule: Keep the citation array empty and make the research gap explicit; do not borrow evidence from another country. - Refresh rule: Preserve prior calibrations only under a comparison-baseline directory and require a blank active calibration set for each new edition. ## D-012 — Country-level conditional app fit - Decision: Keep twelve broad app-fit priors, then author a separate zero-sum ten-app adjustment vector for each storefront inside every multi-country lens before generated ranks are visible. - Reason: Country-specific category existence alone cannot support a claim that conditional app ordering reflects separate evidence for Singapore and Indonesia, Brazil and Mexico, UAE and Saudi Arabia, or South Africa, Nigeria and Kenya. - Bounds: Adjustments use a `0.025` grid from `-0.15` to `+0.15` and sum to zero per category/storefront. Empty local evidence forces all zeros and an explicit gap; it never licenses borrowing another country's evidence. - Refresh rule: Preserve previous app/storefront records as comparison-only, start a blank active authoring directory and reconcile every changed numeric app adjustment in the refresh delta. ## D-013 — Cloudflare Worker delivery convention - Decision: Match the existing project convention with `npm run dev` for a local Cloudflare Worker and `npm run deploy` for a guarded production upload. - Reason: The forecast is a static, data-backed SPA, so Cloudflare Workers Static Assets is sufficient; adding a database or request-handling Worker would create infrastructure without a current product need. - Guardrail: Production deployment runs data validation, type checking and the test suite before Wrangler can upload assets. `npm run deploy:dry-run` exercises the same gate without publishing. - Boundary: This decision adds delivery wiring only. No deployment, custom domain route, edition freeze or publication action was performed. ## D-014 — Product opportunity explanations are separate from rank inputs - Status: Superseded for the active v2 forecast by D-021. Retained here as the historical rule used by the withdrawn continuity draft. - Decision: Store the plain-English product, demand and build explanation in a companion `product-stories/.json` file and join it only after the joint model has computed ranks. - Reason: Better editorial explanation must not silently alter numeric inputs, joint-model hashes or rank order. The separation also makes future refresh changes inspectable. - Reader rule: Write for a bright 16-year-old, use concrete benefits and short sentences, and translate technical terms when they cannot be avoided. - Evidence rule: Inline sources support current premises, never the fictional app or rank. Story sources must already belong to that app's evidence case. - Historic technology rule: The withdrawn draft gave every app an explicit digital-currency and blockchain verdict. V2 no longer treats one named technology as a universal checklist item. ## D-015 — AppStore2031 public identity - Decision: Rename the public project **AppStore2031** and use the supplied faceted `31` artwork in the header, footer and browser icon. - Reason: The name tells a first-time visitor what year is being forecast, and the distinctive mark makes the educational project easier to remember. - Refresh rule: A later forecast is a new immutable edition. It must not silently move or overwrite the dated 2031 claims. - Compatibility boundary: Keep the existing `appstoreforecast` repository and refresh-skill paths plus the separately held `appstoreforecast.com` domain reference. These are internal addresses, not the current public name. - Release boundary: Public name/trademark clearance, deployment and domain attachment remain separate authorised actions. ## D-016 — Research records have readable and source views - Decision: Render preserved Markdown as semantic headings, prose, lists, links, callouts, code and responsive tables by default; retain a one-click exact-source view in the same reader. - Reason: The research is a primary educational product, not a developer attachment. A raw monospace dump makes long methods and evidence tables much harder to understand, while removing source access would weaken scrutiny. - Safety boundary: Parse Markdown into React elements, support the table and task-list features already used by the records, and do not execute raw HTML. - Design rule: Use the existing paper, ink and signal-blue system. Major headings inherit the evidence rail's blue node rather than introducing a separate documentation theme. - Data boundary: The renderer changes presentation only. It does not rewrite the preserved Markdown, research claims, ranks, probabilities or evidence. ## D-017 — Withdraw the continuity-biased first forecast - Decision: Treat edition `2031-2026-07-31` as a superseded research record and remove its categories, listings, ranks and method claims from the active storefront before any freeze, deployment or publication. - Reason: A dated prior-art review found that representative central jobs were already substantially delivered by the evidence cutoff. The scoring and category process rewarded present-day reference classes and did not require five-year temporal distance. - Preservation rule: Keep the evidence and failed forecast inspectable as an audit record. Do not delete evidence or rewrite the historical reasoning to make it appear successful. - Carry-over rule: No old category, listing, score or rank enters method v2 by default. ## D-018 — Generate from future worlds before prior-art comparison - Decision: Horizon scanning, cross-impact worlds, changed actors, marketplace ontology, categories and product candidates are authored without access to current-product comparisons or the previous inventory. - Reason: Looking at current products during generation anchors the result to incremental evolution. Current products are needed later to reject concepts that are already delivered, not to inspire the future catalogue. - Neutrality rule: No named company, product or user-suggested technology is hard-coded into the method. The comparison set is rebuilt dynamically at each evidence cutoff. ## D-019 — Disable and replace the refresh skill - Decision: Disable both matching copies of `app-store-forecast-refresh` until a method-v2 workflow passes the replacement Gauntlet. - Reason: The v1 skill cloned the previous taxonomy and inputs, restricted research primarily to the delta window, preserved unchanged forecasts and fixed the old model version. Those rules would reproduce the anchoring. - Replacement rule: A refresh must rederive worlds, needs, categories and candidates independently, run a new prior-art rejection audit, then compare completed editions only after generation. ## D-020 — Hold Stage D until lived experience is represented - Decision: Archive the incomplete Stage D packet and all three proposals as provenance-only evidence. Publish no canonical taxonomy until independently researched lived-experience needs are combined with the 114 valid institutional needs in a new hash-bound union packet. - Reason: Two independent comparative critics found that the input produced a procurement and commissioned-service catalogue rather than the full range of products ordinary people might browse in a successor app store. - Preservation rule: Keep the incomplete artifacts and their exact hashes, but prohibit their use for category selection, merging, seeding or ranking. - Carry-forward rule: The institutional need set and world basis remain valid; this is an input-completeness correction, not a rewrite of Stages A–C. ## D-021 — Explain causal dependencies, not fashionable technologies - Decision: Every v2 candidate must identify the technical, institutional, legal and physical dependencies that perform a necessary job in its product. Digital currencies, cryptography, blockchain, agent identity, advanced AI or any other named technology appears only when its causal job, readiness, simpler alternative and missing-dependency failure are stated. - Reason: A fixed technology checklist would hard-code the researcher's ideas into every product and make the catalogue look futuristic without proving why the technology is needed. - Reader rule: Explain the dependency so a thoughtful 16-year-old can understand what it enables and what breaks without it. ## D-022 — One category per candidate-author context - Decision: Dispatch one provisional category and its 12 alternative candidate briefs to one fresh external author context. Use a different context for every category and disclose that candidates inside a category may influence one another. - Reason: The rejected three-or-four-category design rendered 3,464,126 bytes for its first delivery and expected one session to create 36 rich products. That exceeded a reliable review and authoring boundary before any candidate had been written. - Delivery rule: Deduplicate shared category, world, need and marketplace-unit records for the author while retaining and reconstructing every immutable per-candidate packet receipt. Size-check the rendered delivery before dispatch. - Refresh rule: Category count is research-derived. A later edition therefore creates exactly one author group for each of its own provisional categories; it never copies the current list or a fixed number of groups. ## D-023 — Stop Stage E for a missing discontinuity world - Decision: Do not seal, audit, rank or publish the 228-candidate draft derived from the six-world set. Preserve it as failed-run evidence while repairing Stages A–D. - Reason: The set covers strong delegated AI but does not include a first-class possible-AGI/post-labour stress case. Without it, the catalogue cannot expose marketplace needs caused by radically cheaper cognitive labour, changed ownership and demand, or contribution and belonging after paid work. - Research boundary: The repair must not claim AGI is certain or assign a probability unsupported by evidence. It must define thresholds, causal paths, regional variants, countercases and invalidators. - Restart rule: Candidate authoring may restart only after affected Stage C needs and Stage D categories pass fresh criticism. Existing candidate names, concepts and ranks do not carry forward automatically. ## D-024 — Model a possible discontinuity without declaring it inevitable - Decision: Add a bounded high-capability stress world only when its capability, economic-substitution and diffusion conditions are explicit. Activation gates classify which world fits a later observed state; they are not a probability that the state will occur. - Reason: Excluding a possible AGI/post-labour discontinuity made the first world set too conservative. Treating AGI as certain would create the opposite error and hide the substantial evidence gaps between benchmarks, dependable work, profitable substitution and global diffusion. - Scarcity rule: Abundant machine cognition does not imply abundant electricity, compute, physical execution, treatment, housing, legal permission, trusted human attention, responsibility or appeal. New needs must follow the complete causal chain, including whichever scarcities remain. - Evidence rule: Unsupported downstream claims stay conditional or move to Watch. A fashionable technology, product launch or weak analogy cannot promote a need. The place-derived robot-data hypothesis was downgraded under this rule. - Restart rule: The repair creates a clean edition and reauthors Stages B-D. It does not patch the old worlds, categories or candidates or make them canonical again. ## D-025 — Use six minimum-sufficient worlds only while their discriminators hold - Decision: The replacement Stage B set contains six unweighted July 2031 worlds: supervised work systems, distributed cognitive dividend, enclosed cognitive economy, maintained physical renewal, hardened service corridors and mediated social life. - Reason: Three closed-allowlist authors independently produced four, five and six worlds. A separate synthesis mapped all 15 proposals and found three repeated clusters plus three irreducible splits. Independent count and coverage critics passed the repaired synthesis at 0.95 and high confidence. - Non-inheritance rule: Six is an observed synthesis result, not the failed edition's count and not a future refresh target. The dynamic protocol accepts any evidence-justified contiguous world set. - W06 rule: Mediated social life remains a separate world only when persistent identity-linked memory, recurring institutional adoption, synthetic attention/status allocation and measured bridge/substitution groups with staffed-capacity displacement form the audited directed loop. If a conjunct or the loop fails, relational mediation becomes a cross-impact inside the matching economic, physical or continuity world. - Probability rule: World membership is a conditional placement decision. No world receives a probability, preference or frequency weight. - Stage C rule: Changed actors and needs are rederived only from the reviewed synthesis and its allowlisted evidence. Old needs and categories are not supplied or carried over. ## D-026 — Make reviewed code-owned receipts the Stage B/C trust roots - Decision: Production Stage B and Stage C compilers use frozen, code-owned approvals for exact reviewed path, byte and SHA-256 receipts. Public APIs do not accept approval overrides and do not export approval factories. - Reason: No finite prose blocklist can prove that every paraphrase of current- app anchoring, numeric certainty or scenario preference has been excluded. Exact reviewed bytes plus independent A verdicts create an auditable human judgement boundary; semantic guards remain defence-in-depth. - Test rule: Dynamic fixture approvals live only in test helpers. Production exports, CLI paths, preparers and downstream compilers reject caller approval, path, count and staging-hook authority. - Refresh rule: A future refresh must receive new independent A verdicts and explicitly advance the approval ID and all exact receipts. It cannot quietly rebind modified research. ## D-027 — Preserve Stage C one-to-one; group only in Stage D - Decision: Every Stage C changed actor and need survives into the canonical synthesis exactly once, in source order and in its original layer. Stage C cannot merge or delete records. - Reason: Early consolidation hid ordinary lived experience and rewarded broad procurement-style buckets in the failed run. Need grouping is an ontology judgement and therefore belongs in Stage D, where every source need remains visible in reconciliation. - Stage D rule: A need may seed, support or constrain several categories only with a material boundary explanation, but it receives one primary disposition and is never dropped. External public duties and research gaps remain in the reconciliation even when they do not seed a marketplace category. - Count rule: The current 60 actors, 41 institutional needs, 33 lived needs, six worlds and nine lenses are observations. No reusable validator treats them as quotas. ## D-028 — Preserve and replace the unsatisfiable Stage D assignments - Decision: The first fresh Stage D packet and its three assignments remain immutable failed-contract evidence. Corrected artifacts use new versioned paths and new receipts; they do not overwrite the files that passed the incomplete automated review. - Reason: All three isolated builders independently found that the assignment registry allowed only `trusted-*` owner IDs while the proposal validator simultaneously required registered `authority-*`, `appeal-*` and `remedy-*` IDs. No proposal could pass both conditions. - Contract rule: Prepared assignments must be rejected unless their exact trusted registry contains at least one usable owner for every required role. A regression must exercise the public preparation path and the downstream proposal validator together, not only each component separately. - Evidence rule: Stage D cannot create an allowlist from Stage C assertions alone. It must replay the reviewed Stage C input/author receipts and bind each cited evidence ID transitively to the approved Stage B source universe. - Verdict rule: Each semantic author-verdict receipt and required check name must match the exact replayed Stage C author output set. Matching only the number and shape of verdict records is insufficient. - Transaction rule: Packet paths, assignment paths and all reserved proposal paths remain collision-checked through the final atomic commit. A collision introduced after preflight aborts the complete write and preserves the colliding file. - Restart rule: The builders restart in fresh contexts only after the corrected bytes pass independent hostile criticism. No draft produced against the bad assignment may enter synthesis. - Version rule: `internal-dynamic-stage-d-proposal-v3` is the authorised successor to the unsatisfiable proposal v2 contract. The corrected Stage D input protocol has its own v2 identifier and directory; every generated assignment must explicitly bind proposal v3. Failed root-v1 handoff paths are mechanically denied rather than relying on documentation alone. - Acceptance record: The corrected handoff passed independent exact-byte criticism at A/0.995. Its packet receipt is `772b7407ffa6205b7b3a9d09c6bcec7e5c1ea038b9d2e8a201854d3fe44432df`; assignment receipts are `dd4d3097734bde258fdf601003649bd475e76585b741575063462c51397683fd`, `cf16d38e5b064027ca65721dc23f3ac90488c86ead08b85680353f973f5e17f7` and `143f76566d2826c2336ffba2c7e25e440fddb4b1ffb806fe7e1835cac51665aa`. ## D-029 — Keep geographic-lens counts evidence-derived - Decision: The storefront validates a non-empty unique lens set and displays its authored count. It does not require or label twelve lenses. - Reason: The fresh approved handoff currently derives nine lenses. Both nine and twelve are observations from particular research designs, not permanent truths about how many geographic paths a later forecast must represent. - Downstream rule: Ranking, projection and refresh tooling must bind the exact reviewed lens set for its edition and reject missing, duplicate or substituted lenses without embedding a count from an older edition. ## D-030 — Split unlike causal finishes without weakening no-loss - Decision: Stage D proposal contract v4 permits one or more consecutive causal paths for each applicable world. The collapsed world groups must exactly match the category's ordered applicable-world list, and every category need must appear exactly once across those paths. - Reason: Builder B's v3 repair preserved 74 different finishes, harms and recoveries by giving each need its own path, but v3 required exactly one path object per world. That rule rewarded broad prose which could mention many needs while preserving only one of them. - No-loss rule: A path cannot cite an unknown, out-of-category or world- incompatible need. A need cannot be missing or repeated, even across two different world groups. World groups cannot be reordered or interleaved. - Readability rule: The existing per-field prose limits remain in force. An artifact which satisfies the new grouping rule can still fail for language that is too long or unclear; contract repair is not permission to lower the bright-sixteen-year-old standard. - Version rule: Proposal v4 is authorised only by the new `approved-dynamic-stage-d-input-v3` packet and assignments under `stage-d-fresh/v3`. Every v2 artifact remains exact historical evidence and cannot be silently reinterpreted under v4. - Acceptance record: The focused proposal and input suites pass 66/66. The new packet receipt is `4c9d295ad742ac3a7b3bdc1c92966a24557f8cc87c875b6d185f4d0e5206cccd`; assignment receipts are `743cf0ada1c893aa0f1e0daa75ff0c1c5526b3a4cb8506d5f5b401455bb85a03`, `fa3f399bc837949afa2819283ea5c5f50ae2a2692c033b715ec9bedbc1698b9b` and `9b9a2dda2184c4ddd2ede9b9573f58f8db4d0ab5cd0a53f315f5a3b2b39770b3`. - Discovered-content rule: The exact B R4 rebound clears the v4 world and need invariants, then fails the unchanged prose limit in 137 fields. That is a versioned Builder B language repair, not a reason to weaken the contract or hide the failed file. ## D-031 — Make canonical synthesis replay the evidence it claims to combine - Decision: A Stage D synthesis report cannot validate a canonical ontology by describing it. The gate must replay the exact proposal-v4 assignment and full proposal contract against the approved Stage B/C sources, then bind the exact canonical bytes and complete collision matrix. - Reason: The first synthesis core passed 11 tests while accepting a fixture that was not a valid v4 proposal. Hostile attacks added present-product input, arbitrary assignment bytes, an omitted world, extra proposal fields and a duplicate collision record without being rejected. - Approval rule: Accepted alternatives come only from a code-owned Stage D alternatives approval which binds each exact assignment, proposal and fresh independent A-grade synthesis-scoped verdict. Prose containing the words `independent` or `synthesis` is not evidence of either condition. - Dynamic rule: Need, world, lens, category and unit counts are observations derived from approved source bytes. The current 74 needs and six worlds are not reusable refresh quotas. - No-loss rule: The synthesis report accounts for every category in every accepted alternative as retained, merged or rejected, with exact source and target hashes. Every approved world has either a retained category or a typed unresolved gap tied to that world's exact needs. - Collision rule: Recombination always triggers the complete v4 collision replay. Each public re-audit record additionally binds both category definitions and need sets; an earlier alternative's collision receipt cannot be copied into the canonical result. - Publication rule: A valid synthesis remains unapproved until separate fresh structural and semantic critics return A and a second code-owned canonical approval advances. A report, envelope or synthesizer cannot approve itself. - R2 boundary record: The repaired internal core passed fresh hostile review at A/0.995, including exact v4 replays and a six-need dynamic fixture. The first production-wrapper review found alternate-path receipt relabelling and an unbound canonical lens list. R2 path-locks proposal/report receipts, checks the assignment's exact ordered lenses against the approved packet and accepts only `{projectRoot}`. Fresh hostile re-review returned A/0.995, scoped only to this production boundary. An injected test authority or validated report is still not canonical publication authority. ## D-032 — Admit Stage D to Stage E through one narrow public authority - Decision: The only Stage D authority Stage E may consume is the return value of `validateReviewedStageDCanonicalApproval({projectRoot})` from the public canonical-approval module. - Exact result: Synthesis R2 contains eight retained categories, six provisional and two watch. Fresh structural and semantic critics returned A at 0.997 and 0.995. The separate canonical-approval boundary returned A at 0.995 after recursively verifying 54 nested receipts. - Exclusion rule: Failed R1 verdicts, a synthesis report, a proposal, critic wording, an internal core function or a digest cannot authorize Stage E. - Scope rule: Canonical approval permits ontology use by Stage E only. It grants no authority for candidate content, inventory, ranking, storefront copy, public publication, deployment or domain changes. - Watch rule: Categories 007 and 008 remain visible research outcomes but are excluded from automatic Stage E candidate publication until their explicit promotion evidence is satisfied. ## D-033 — Keep approval identity separate from need content - Decision: Stage E uses the canonical approval identity to prove each need's ID, layer and source hash, but reads world applicability and product-shaping content only from the exact hash-bound need record. - Reason: The approval identity deliberately does not duplicate `worldIds`. Treating it as the content record crashed real author-packet preparation and would have weakened the source boundary if fixed by copying fields into it. - Normalisation rule: Stage C lower-case world IDs are matched to the reviewed upper-case world IDs without changing either source artifact. - Dispatch result: Six provisional categories receive 12 candidate briefs each; two watch categories receive none. This is an observed edition result, not a reusable category or inventory quota. ## D-034 — Refreshes must rederive their own dimensions - Decision: The project and installed refresh skill derive category, candidate, world and geographic-lens counts from each new edition's reviewed artifacts. - Reason: Fixed examples from an older design can quietly become generation or validation targets even when the written method says categories are unknown. - Regression rule: Governance tests reject fixed 12-category/120-candidate and six-world/12-lens language, while preserving exactly six independent final Gauntlet critic scopes as a quality-control design rather than a forecast dimension. ## D-035 — Validate the direct-v4 edition without manufacturing legacy research files - Decision: The clean active edition is validated from its exact 20-artifact research snapshot, public Stage D approval and schema-4 Stage E packet tree. It must not create `sources/claims/horizons/worlds/ontology` files merely to satisfy an older schema-3 intermediate validator. - Reason: The first active validation route still tried to read the withdrawn schema-3 ontology and four legacy Stage A-D lifecycle records even though the direct-v4 integration deliberately preserves a different, receipt-bound research structure. - Validation rule: Preparation counts, provisional and watch category sets, need/world/lens counts, source receipts, packet hashes, category groups and output roots are rederived from the edition-local v4 boundary. Each author group is replayed through the same loader used by its clean-room delivery. - Projection rule: Public evidence files may be created later as deterministic reader and ranking projections. They cannot become substitute authority for the reviewed v4 research or recreate the invalidated ontology lineage. ## D-036 — Project public evidence without changing research authority - Decision: The clean edition's `sources.json` and `claims.json` are a deterministic public-reader projection of the exact Stage B-bound registries and edition-local reviewed Stage B–D snapshot. They are not a new research input and cannot approve candidates, ranks or publication. - Identity rule: Evidence identifiers remain byte-for-byte meaningful, including uppercase and dotted IDs. The active validator does not force them through the obsolete lower-case product-ID grammar. - Coverage rule: Every evidence ID used by the direct-v4 snapshot must resolve; source-to-claim reverse indexes and source/claim input receipts must match exactly. Registry or edition-local receipt drift fails validation. - Disclosure rule: A missing exact access date is represented by the edition cutoff only as a projection boundary, with an explicit qualification; it is never presented as a claimed visit date. - Result: 463 source records and 264 claims resolve all 129 referenced evidence IDs. The exclusive writer produced SHA-256 `d4aa775db4fcf014724838bde4b367335aa69067d08e1e7a1fe6d2f07ebf25bf` for sources and `835a4505d204b7d19c2fd80fe5e2c2a0e63bc068c2b9ab821ae1d3ca7de61094` for claims. ## D-037 — Mechanically protect author metadata; author only the judgement - Decision: Do not weaken candidate validation when a long-form author changes a locked world, timestamp or required array. Reject and archive the whole group, then improve the hand-off so immutable identity and coverage fields are mechanically scaffolded while the independent author supplies the product idea and explanations. - Reason: The second wave reproduced transcription errors despite stronger prose instructions: categories 001 and 003 changed a candidate's applicable world, category 002 supplied too short a causal chain, and the later isolated category 004 and 005 runs changed applicable worlds again. These are workflow-shape failures, not evidence that the underlying drafts passed. - No-salvage rule: Failed group prose cannot be copied into a fresh context. Failed files stay outside the active edition as transparent correction history. ## D-038 — Treat author time as receipt metadata, not forecast evidence - Decision: Before live session integration, `authoredAt` must be a valid ISO timestamp but is not compared with packet creation. The integrator replaces it with the exact externally verified task completion time. Once a session receipt exists, that integrated time must follow packet creation. - Reason: An author supplied a schema placeholder 10 milliseconds before packet creation even though the candidate hash deliberately excludes that field and the integrator never retains it. Rejecting product judgement for that value was a false acceptance trap rather than a research safeguard. - Boundary: Author identity, packet receipt, category, unit, worlds, evidence, substantive prose and every other candidate field remain exact and hash-bound. This decision does not permit guessed session times or weaken the externally verified receipt. ## D-039 — Show the evidence ladder instead of a JSON wall - Decision: A listing explains three separate layers in reading order: current evidence, forecast inference and the fictional product consequence. Exact raw records stay available in the research library, but are not the primary explanation. - Reason: Credibility requires both inspectable sources and a clear account of how the forecast moves beyond them. A raw evidence-reference array exposed data without teaching that reasoning. - UI rule: Scenario and listing pages use plain language suitable for a thoughtful 16-year-old, preserve limitations and uncertainty, link to the original source where available and never present imagined product or review material as observed fact. ## D-040 — Authors write product judgement; the integrator owns candidate identity - Decision: New author groups write only the twelve substantive candidate sections in `candidate-content.json`. They cannot write candidate identity, schema/protocol, authorship, category, marketplace unit, top-level world coverage, geography row IDs, scenario row IDs or receipt pointers. - Reason: Multiple independent v2 groups continued to change one machine field despite an explicit immutable scaffold. Repeating the same prompt was no longer a useful quality loop. Immutability must be a property of the file contract, not an instruction that an author can accidentally violate. - Merge rule: The integrator constructs `candidate.json` by explicitly selecting authored sections and injecting packet-owned fields. It adds geography and world row IDs by exact array position. Wrong row counts or any author-supplied ID fail; no judgement is repaired, defaulted, reordered or normalised. - Receipt rule: V3 binds both the exact authored file bytes and the deterministic canonical projection. V2 remains independently replayable so the accepted category 002 receipt and hashes are not rewritten. Unknown or mismatched protocol versions fail closed. - No-salvage rule: The new format applies only to fresh contexts. None of the prose in rejected or interrupted v2 groups may seed a v3 author. ## D-041 — Canonicalise an exact world identity, never infer a world choice - Decision: In v3 only, a nested authored world ID may be projected to the packet's canonical spelling when and only when there is exactly one case-insensitive allowed match. This covers the reviewed Stage C lower-case and Stage D upper-case representations of the same world. - Boundary: Unknown, out-of-packet, ambiguous or duplicate-after-projection IDs fail. The rule applies only to the three nested world-reference arrays in evidence anchors, build dependencies and readiness steps. It does not select a world, change evidence, normalise prose or alter any v2 candidate. - Receipt rule: The exact authored bytes and payload SHA preserve the writer's representation. The deterministic canonical candidate and its separate hash use the packet identity, so both the input and projection remain auditable. ## D-042 — Distinguish canonical world IDs from receipt shorthand in the author instruction - Decision: V3 authors must copy nested world strings exactly and case-sensitively from `assignment.authoredSelectionLimits.allowedWorldIds`. When `exactWorldArrayWhenSingleWorld` exists, the entire supplied array must be copied verbatim. `W01`-style receipt, source or display shorthand is not an authored world ID unless that exact string is explicitly allowed. - Reason: Five fresh content-only groups independently chose the right-looking `W01`, `W03` or `W05` receipt label instead of the packet's canonical world identifier. The strict validator correctly rejected all sixty files, but the repeated pattern showed that the signed bootstrap did not explain the two ID systems clearly enough. - Boundary: The canonical projection and validator are unchanged. They still reject unknown, out-of-packet, ambiguous and duplicate world choices. This is an instruction repair, not an alias rule or a way to salvage failed prose. - Compatibility: The accepted category 002 v2 bootstrap, external receipt and candidate-set hashes remain byte-for-byte frozen. Only fresh v3 sessions use the clearer bootstrap. ## D-043 — Do not ask an author to choose when the packet permits one world - Decision: Author protocol v4 removes `worldIds` from the three nested authored row shapes. Any author-supplied nested `worldIds` key fails exact-key validation. The integrator injects the candidate packet's complete exact world array into every canonical evidence-anchor, dependency and readiness row after the authored content has passed validation. - Reason: Even after the signed v3 bootstrap explicitly prohibited shorthand and required exact per-assignment copying, four of five fresh groups copied a valid world from another candidate. Every active packet currently permits exactly one world, so transcription was not a substantive judgement and repeated retries could not improve the forecast. - Authorship boundary: Authors still originate the product promise, causal explanation, evidence choices, build dependencies, readiness sequence, regional and scenario judgements, harms, authority limits, resolution test and counter-case. Only the packet-owned world membership is injected. - Compatibility: Integrated v2 category 002 and v3 category 003 remain byte-bound and replay under their original protocols. Mixed v2/v3/v4 receipt validation is required; unknown protocols fail closed. ## D-044 — A closed critic corpus must include the complete authorable contract - Decision: Collision protocol v2 gives each fresh critic the complete exact top-level and nested result schema, all derived-decision and action rules and candidate-specific anchor tuples needed by the validator. The critic may use only that receipt-bound corpus and cannot author its own session receipt. - Reason: The previous compact delivery prohibited additional reads but omitted several exact structures the validator required. A compliant critic could therefore fail through undisclosed formatting rather than a bad collision judgement. The shortest per-domain anchors were also not guaranteed to satisfy the validator's candidate-specific phrase rule. - Recovery rule: A legitimate pre-seal `revise` or `reject` is preserved in a hash-inventoried no-salvage archive. Every implicated full author group is removed from active use and must be freshly re-authored, after which the complete set is recompiled, repacketed and reviewed by fresh critics. Archived author and critic contexts can never re-enter later integration. - Boundary: Collision decisions, pair coverage, cross-category assessment, context independence, sealing and rollback remain strict. This repair does not touch post-seal present-day prior-art replacement. ## D-045 — Present-day rejection must have a production replacement transaction - Decision: If a Stage F audit leaves a category with fewer than ten surviving candidates, use the versioned production replacement cycle rather than manually reinstalling a fixture tree. Each removed candidate receives one never-used successor ID, unchanged Stage E artifacts remain byte-exact and the prior audit history remains immutable. - Isolation rule: Fresh replacement authors receive only isolated replacement packets with no rejected-candidate, audit, current-product or prior-art material. Fresh external authors and collision critics must replay from their exact session transcripts before a successor set can be resealed. - Transaction rule: The replacement registry, full collision re-review, successor protocol tree and new seal install atomically. A late failure rolls back, and an interrupted committed cleanup can be recovered without editing historical artifacts. - Reason: The first Stage F implementation understood replacement lineage in fixtures but had no safe public path to prepare authors, integrate critics or reseal after live audit artifacts existed. Starting an audit without this path could strand an otherwise honest edition after a legitimate rejection. ## D-046 — Freeze every dependency of a signed delivery while authors are active - Decision: From an external author's first immutable delivery retrieval until receipt integration or explicit interruption, do not change any code or contract that can alter the reconstructed delivery or validator output. Run adjacent protocol repairs before dispatch, then hold that boundary fixed. - Reason: Two locally valid v4 groups could not replay their first delivery after collision and Stage F hardening legitimately changed shared validation dependencies during their turns. The content had not failed, but the corpus could no longer be proven byte-identical. Two zero-file sessions with the same exposure were stopped rather than allowed to waste more work. - No-salvage rule: Completed groups affected by delivery drift are archived in full and freshly authored after the dependency tree stabilises. A matching bootstrap string is insufficient when the bootstrap retrieves changed delivery bytes. ## D-047 — Stop the oversized Stage F audit instead of redesigning it again - Decision: No Stage F category-audit output is accepted for edition `2031-2026-08-02`. The sealed worlds, needs, categories and 72 candidates remain valid inputs; only the uncompleted present-day overlap audit is stopped. - Evidence: The final fresh audit delivery was 360–410 KB per category. In live external contexts the permitted retrieval repeatedly exposed only the first candidate and reported roughly 78,000–85,000 omitted tokens. The auditor could not inspect candidates 2–12 or their exact bindings. - Boundary: Earlier interrupted contexts wrote no accepted output or receipt. Their prose is not reused. The public method discloses incomplete semantic current-market coverage rather than claiming global novelty. - Reason: A sixth transport redesign would improve proof machinery, not the forecast. The user explicitly required a bounded finish rather than another protocol loop. ## D-048 — Use one transparent bounded Top 10 judgement per category - Decision: Six fresh category synthesizers compare all twelve sealed concepts in one category, select exactly ten and explain the two exclusions. - Scoring: Future distance ×5, need scale ×4, global breadth ×3, marketplace clarity ×3, 2031 delivery readiness ×3 and trust/safety ×2. Each dimension is an integer from 1 to 5, for a maximum total of 100. - Boundary: Scores are authored judgements, not probabilities. Ties require a written causal judgement. Every row explains its position, the adjacent comparison, move conditions and strongest counter-case; rank 10 compares with the strongest excluded candidate. - Outcome: Six categories, 60 selected listings and 12 explicit exclusions. Category and candidate counts remain observations of this edition, never quotas for a refresh. ## D-049 — Use a bounded exact-name screen and state what it cannot prove - Decision: Search every selected fictional name with quoted app, software and company terms. Replace material collisions and repeat the search until all 60 names have `no-material-collision-found`. - Evidence: The first screen found numerous real collisions, including existing apps, software products and technology organisations. Twenty-eight names were replaced and searched again; the edition preserves queries, URLs, reasons and the final row for every candidate. - Boundary: This is not trademark, company-name, domain, language, cultural or legal clearance. Similarity and rights questions still require professional review before real use. ## D-050 — Keep the final synthesis edition-scoped and make refresh reproduce the method - Decision: Category syntheses and name audits live under `data/editions/2031-2026-08-02/workflow/final-synthesis/`. The public projection and research library are compiled from those edition-scoped records. - Skill: The repository and installed `app-store-forecast-refresh` skill copies now specify the future-world-first stages, the bounded overlap-review rule, the 100-point Top 10 judgement, plain-language listings and bounded name screen. The abandoned audit-v3, causal-v8 and name-v3 protocols are no longer active refresh requirements. - Release boundary: The edition remains `researching` with `asOf: null`. These changes do not authorise freeze, deployment, domain work, commit or push. ## D-051 — Release the finished forecast through bounded product checks - Decision: Preserve the older protocol-laboratory tests as provenance, but use the compiled final forecast, public library, refresh-skill governance, typography and Worker wiring as the active local release gate. - Reason: The abandoned Stage A–H experiments assert historical intermediate states such as zero active listings and cannot truthfully grade the completed 60-listing product. Keeping them in the default command would mistake failed research paths for current acceptance criteria. - Proof: The active suite passes 30/30, the final synthesis and projection validators pass, and signed-out mobile and desktop journeys each show six categories, ten rows in the selected category, six worlds and zero browser errors. Closing a product sheet returns focus to its originating row or search control, and explanatory detail text is at least 16px. - Crash recovery: The final critic first found the pre-crash local preview process accepting connections without returning bytes. That single process was terminated and restarted; HTTP 200 and the complete route proof then passed, and the same critic returned `PASS`. - Boundary: This is a local release candidate only. No deployment, domain attachment, freeze, publication, commit or push is authorised by this check. ## D-052 — Publish the working forecast at appstore2031.com - Decision: The user explicitly authorised deployment of the current working forecast to the purchased Cloudflare-managed domain `appstore2031.com` on 3 August 2026. - Route: The `appstore2031` static-assets Worker is the origin for the apex Custom Domain. Cloudflare manages the generated DNS record and certificate. - Canonical host: Crawlable pages, structured data, the sitemap and citation guidance use `https://appstore2031.com`. - Boundary: This authorises this Worker deployment and apex-domain attachment. It does not freeze the forecast, add other domains, commit, push or authorise unrelated production changes elsewhere in the workspace.