Authored fictional workload. Relevance is by construction: the topic labels and required answer sources are frozen before runs. Topic relevance: 45.5% of sections. 63,155 characters.
Baseline: anthropic/claude-opus-5. Foreman: anthropic/claude-opus-5 + openai/gpt-5.6-terra. This compares the complete product, including planning and independent review. The planner receives a compact document index; workers receive selected sections verbatim. All calls count toward total input tokens and estimated cost.
Model mappings and catalog prices captured 2026-10-08T21:02:01.610021+00:00. Prices below are USD per million tokens; measured costs use reported usage and applicable cached-token pricing.
| Gateway ID | Upstream ID | Input | Output |
|---|---|---|---|
| anthropic/claude-opus-5 | claude-opus-5 | $5 | $25 |
| openai/gpt-5.6-terra | gpt-5.6-terra | $2 | $12 |
SHA-256: ef68155868a7f3ff44ba0e0a1e9fc6e176846b8084dfd9e664ae05aa714ca8a6
Not run: full matrix gated on successful two-arm smoke.
[]
Run one Foreman task with your connected provider keys. Maximum mission spend: $1. This live sample does not change the published benchmark results.
Write a SQL query returning the three highest-paid employees per department, handling ties.
Frozen key: "Correct window function partitioned by department. FAIL if any Tessellate detail appears."
Required source: General knowledge; no workspace details
What is the sediment capacity factor in the erosion pass, and what does it most affect?
Frozen key: ["3.2"]
Required source: Erosion Parameters — Tuning Log
What would have to change for multiplayer to work, and what is the estimated performance cost?
Frozen key: ["15","20"]
Required source: Multiplayer — Current Thinking
What is the Poisson-disc radius for the scrub biome?
Frozen key: "2.1"
Required source: Scatter System
| Section | Topic relevant |
|---|---|
| Terrain Generation — Core Pipeline | Yes |
| Chunk Budget and Performance Targets | Yes |
| Erosion Parameters — Tuning Log | Yes |
| Scatter System | Yes |
| Save Format — Version 3 | No |
| Multiplayer — Current Thinking | Yes |
| Art Direction — Reference and Principles | No |
| Build and Release Process | No |
| Playtest Round 4 — Findings | No |
| Scratch — terrain team | No |
| Audio Asset Packaging | No |
# Tessellate Studio — Internal Workspace Memory > **Corpus 03.** Topic relevance: **5/11 sections (45.5%)**. Full pre-run labels are in corpus-manifest.json. > bears on the prompts. Tests that selection does not over-prune when context genuinely matters. > Fictional studio. No real company, person, or product is depicted. --- ## DOC: Terrain Generation — Core Pipeline Terrain is generated per-chunk on demand. A chunk is 256×256 world units, stored as a heightfield plus a biome mask plus a scatter list. Generation order matters and has been reordered twice: 1. **Continent mask** — very low frequency noise, determines land versus ocean. Deterministic from world seed alone. 2. **Elevation** — ridged multifractal, 6 octaves, warped by a separate low-frequency field to avoid the characteristic "same shape everywhere" look. 3. **Hydrology** — rivers carved by a downhill tracing pass from local maxima. This is the expensive step. 4. **Erosion** — hydraulic erosion, 40 iterations. Applied after hydrology so rivers are respected. 5. **Biome assignment** — from elevation, latitude, and a moisture field derived from distance to water. 6. **Scatter** — trees, rocks, detail meshes, placed by Poisson-disc sampling with biome-specific density. The original order ran erosion before hydrology and the rivers looked wrong — they ignored the eroded valleys and cut across them. Swapping fixed it at the cost of a second erosion-respecting pass in hydrology. ### Determinism Everything must be reproducible from world seed plus chunk coordinate. No global state, no dependence on generation order between chunks. This is enforced by a test that generates a set of chunks in random order across multiple threads and compares hashes against a golden set. This constraint rules out some techniques. True hydraulic erosion wants to simulate across chunk boundaries; ours operates on a padded region and accepts slight seams, which are hidden by the scatter pass. --- ### Operational review notebook **Provenance exercise for Terrain Generation — Core Pipeline.** We walked through the document with a programmer comparing a capture with a designer annotation. The reviewer started from the seed, build identity and camera location of the captured scene, then followed the work to the point where another person would rely on it. The awkward case was a visual comparison made from scenes generated by different builds. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream. **Permissions exercise for Terrain Generation — Core Pipeline.** We walked through the document with an external contributor delivering a package through the asset portal. The reviewer started from the permitted upload destination and the ownership of the source material, then followed the work to the point where another person would rely on it. The awkward case was a package containing reference images whose rights are not recorded. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives. **Exceptions exercise for Terrain Generation — Core Pipeline.** We walked through the document with a build engineer isolating a corrupt optional asset. The reviewer started from the asset identifier and a small reproducible fixture, then followed the work to the point where another person would rely on it. The awkward case was an unrelated missing texture obscuring the actual geometry defect. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion. **Rehearsal exercise for Terrain Generation — Core Pipeline.** We walked through the document with a producer arranging a playtest without unfinished campaign content. The reviewer started from a dedicated test save and a known starting scene, then followed the work to the point where another person would rely on it. The awkward case was a tester importing an old local save and describing it as a fresh game. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally. **Archiving exercise for Terrain Generation — Core Pipeline.** We walked through the document with a technical artist retiring a superseded material library. The reviewer started from the source graph revision and the export manifest, then followed the work to the point where another person would rely on it. The awkward case was a cached thumbnail showing a material that is no longer in the package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it. ## DOC: Chunk Budget and Performance Targets Target: a chunk generates in under **12ms** on the reference machine, so streaming four chunks per frame at 60fps leaves headroom. Current measured breakdown on the reference machine: | Stage | Time | Notes | | --- | --- | --- | | Continent mask | 0.3ms | Cached per region, usually free | | Elevation | 2.1ms | SIMD path, was 7ms before | | Hydrology | 5.4ms | The problem | | Erosion | 2.8ms | 40 iterations | | Biome | 0.6ms | | | Scatter | 1.2ms | | | **Total** | **12.4ms** | Just over | Hydrology dominates and resists optimization because the downhill trace is inherently serial per river. We parallelize across rivers, which helps on chunks with many rivers and does nothing on chunks with one long one. Idea not yet tried: precompute a coarse flow field at region level and use it to seed the per-chunk trace, turning a search into a lookup for most of the path. --- ### Operational review notebook **Permissions exercise for Chunk Budget and Performance Targets.** We walked through the document with an external contributor delivering a package through the asset portal. The reviewer started from the permitted upload destination and the ownership of the source material, then followed the work to the point where another person would rely on it. The awkward case was a package containing reference images whose rights are not recorded. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives. **Exceptions exercise for Chunk Budget and Performance Targets.** We walked through the document with a build engineer isolating a corrupt optional asset. The reviewer started from the asset identifier and a small reproducible fixture, then followed the work to the point where another person would rely on it. The awkward case was an unrelated missing texture obscuring the actual geometry defect. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion. **Rehearsal exercise for Chunk Budget and Performance Targets.** We walked through the document with a producer arranging a playtest without unfinished campaign content. The reviewer started from a dedicated test save and a known starting scene, then followed the work to the point where another person would rely on it. The awkward case was a tester importing an old local save and describing it as a fresh game. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally. **Archiving exercise for Chunk Budget and Performance Targets.** We walked through the document with a technical artist retiring a superseded material library. The reviewer started from the source graph revision and the export manifest, then followed the work to the point where another person would rely on it. The awkward case was a cached thumbnail showing a material that is no longer in the package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it. **Accessibility exercise for Chunk Budget and Performance Targets.** We walked through the document with a player changing contrast and motion settings. The reviewer started from the resulting on-screen state rather than the position of a slider, then followed the work to the point where another person would rely on it. The awkward case was an interface preserving the slider while losing its effect after a scene change. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe. ## DOC: Erosion Parameters — Tuning Log Hydraulic erosion has too many knobs. Recording what we settled on and why. - **Iterations: 40.** Below 25 the terrain looks unfinished. Above 60 everything converges toward the same smooth valley shapes and loses character. 40 is where it stops improving visibly. - **Rain amount: 0.012 per cell per iteration.** Higher values produce deep gorges everywhere. - **Evaporation: 0.018.** Tuned against rain; the ratio matters more than either number alone. - **Sediment capacity factor: 3.2.** This is the one that changes the look most. Low values give gentle slopes, high values give dramatic cliffs and debris fans. - **Minimum slope: 0.0008.** Prevents division blowup on flat ground. Found by hitting the blowup. - **Deposition rate: 0.25**, **erosion rate: 0.35.** Slightly favouring erosion over deposition keeps valleys from silting up over long generation. The art director's note on all of this: "less uniform." We addressed it by varying sediment capacity spatially using the same warp field as elevation, which gave regional character without new parameters. --- ### Operational review notebook **Exceptions exercise for Erosion Parameters — Tuning Log.** We walked through the document with a build engineer isolating a corrupt optional asset. The reviewer started from the asset identifier and a small reproducible fixture, then followed the work to the point where another person would rely on it. The awkward case was an unrelated missing texture obscuring the actual geometry defect. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion. **Rehearsal exercise for Erosion Parameters — Tuning Log.** We walked through the document with a producer arranging a playtest without unfinished campaign content. The reviewer started from a dedicated test save and a known starting scene, then followed the work to the point where another person would rely on it. The awkward case was a tester importing an old local save and describing it as a fresh game. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally. **Archiving exercise for Erosion Parameters — Tuning Log.** We walked through the document with a technical artist retiring a superseded material library. The reviewer started from the source graph revision and the export manifest, then followed the work to the point where another person would rely on it. The awkward case was a cached thumbnail showing a material that is no longer in the package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it. **Accessibility exercise for Erosion Parameters — Tuning Log.** We walked through the document with a player changing contrast and motion settings. The reviewer started from the resulting on-screen state rather than the position of a slider, then followed the work to the point where another person would rely on it. The awkward case was an interface preserving the slider while losing its effect after a scene change. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe. **Review exercise for Erosion Parameters — Tuning Log.** We walked through the document with a lead comparing two proposals for the content workflow. The reviewer started from the artist time and build time measured separately, then followed the work to the point where another person would rely on it. The awkward case was a faster export that leaves every recipient to repair the imported package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated. ## DOC: Scatter System Places trees, rocks, grass, and detail props. Must be dense enough to look alive and sparse enough to render. Poisson-disc sampling with per-biome radius. Radii: - Dense forest: 1.8 units - Light forest: 3.4 units - Scrub: 2.1 units (smaller objects, closer together) - Alpine: 6.0 units - Desert: 8.5 units Objects are placed in two passes. First pass places "anchor" objects — large trees, boulders — using the biome radius. Second pass places detail at a much smaller radius, rejecting positions that collide with anchors. LOD is handled by the renderer, not here, but scatter writes an importance value per object that the renderer uses to decide cull order. Importance is roughly size times distinctiveness; a lone tree on a ridge scores higher than one of four hundred in a forest. Slope rejection: nothing places on slopes above 38 degrees except a specific set of cliff-dwelling props. --- ### Operational review notebook **Rehearsal exercise for Scatter System.** We walked through the document with a producer arranging a playtest without unfinished campaign content. The reviewer started from a dedicated test save and a known starting scene, then followed the work to the point where another person would rely on it. The awkward case was a tester importing an old local save and describing it as a fresh game. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally. **Archiving exercise for Scatter System.** We walked through the document with a technical artist retiring a superseded material library. The reviewer started from the source graph revision and the export manifest, then followed the work to the point where another person would rely on it. The awkward case was a cached thumbnail showing a material that is no longer in the package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it. **Accessibility exercise for Scatter System.** We walked through the document with a player changing contrast and motion settings. The reviewer started from the resulting on-screen state rather than the position of a slider, then followed the work to the point where another person would rely on it. The awkward case was an interface preserving the slider while losing its effect after a scene change. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe. **Review exercise for Scatter System.** We walked through the document with a lead comparing two proposals for the content workflow. The reviewer started from the artist time and build time measured separately, then followed the work to the point where another person would rely on it. The awkward case was a faster export that leaves every recipient to repair the imported package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated. **Handover exercise for Scatter System.** We walked through the document with an artist passing a work-in-progress asset to a technical designer. The reviewer started from the source file revision and the intended scene placement, then followed the work to the point where another person would rely on it. The awkward case was an exported asset being mistaken for the editable original. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete. ## DOC: Save Format — Version 3 Version 3 replaced the naive full-world dump with a delta format. The insight: terrain is deterministic from seed, so we never need to save it. We save only what the player changed. A save file is the world seed, a list of modified chunks, and per-modified-chunk a sparse diff. Sizes went from 180MB typical to under 2MB typical. Risks of this approach, acknowledged: - If generation changes, old saves generate different terrain underneath the player's modifications. We version the generator and keep old versions available. This means we can never delete a generator version, which will become a maintenance burden. - A player who modifies a very large area gets a large save. The worst case we have seen in testing is 41MB from someone who flattened a mountain range. Chunk diffs use run-length encoding on the heightfield delta, which compresses well because modifications tend to be contiguous. --- ### Operational review notebook **Archiving exercise for Save Format — Version 3.** We walked through the document with a technical artist retiring a superseded material library. The reviewer started from the source graph revision and the export manifest, then followed the work to the point where another person would rely on it. The awkward case was a cached thumbnail showing a material that is no longer in the package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it. **Accessibility exercise for Save Format — Version 3.** We walked through the document with a player changing contrast and motion settings. The reviewer started from the resulting on-screen state rather than the position of a slider, then followed the work to the point where another person would rely on it. The awkward case was an interface preserving the slider while losing its effect after a scene change. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe. **Review exercise for Save Format — Version 3.** We walked through the document with a lead comparing two proposals for the content workflow. The reviewer started from the artist time and build time measured separately, then followed the work to the point where another person would rely on it. The awkward case was a faster export that leaves every recipient to repair the imported package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated. **Handover exercise for Save Format — Version 3.** We walked through the document with an artist passing a work-in-progress asset to a technical designer. The reviewer started from the source file revision and the intended scene placement, then followed the work to the point where another person would rely on it. The awkward case was an exported asset being mistaken for the editable original. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete. **Provenance exercise for Save Format — Version 3.** We walked through the document with a programmer comparing a capture with a designer annotation. The reviewer started from the seed, build identity and camera location of the captured scene, then followed the work to the point where another person would rely on it. The awkward case was a visual comparison made from scenes generated by different builds. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream. ## DOC: Multiplayer — Current Thinking Not committed to multiplayer, but designing so as not to preclude it. The determinism constraint already buys us most of what we would need: two clients with the same seed generate identical worlds without syncing terrain. Only modifications need syncing, and those are already a compact delta. What would need to change: - Scatter currently uses a thread-local RNG seeded per chunk. Fine, but the ordering within a chunk is not guaranteed across platforms due to floating-point differences in the Poisson rejection test. For single player this is invisible. For multiplayer it means two clients could see a tree in slightly different places. - The erosion pass uses a fast inverse square root approximation that differs between our ARM and x86 builds in the last bits. Same problem, bigger blast radius. Fixing both means a strict-determinism mode with fixed-point or carefully constrained float math, at a performance cost we have estimated at 15–20%. --- ### Operational review notebook **Accessibility exercise for Multiplayer — Current Thinking.** We walked through the document with a player changing contrast and motion settings. The reviewer started from the resulting on-screen state rather than the position of a slider, then followed the work to the point where another person would rely on it. The awkward case was an interface preserving the slider while losing its effect after a scene change. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe. **Review exercise for Multiplayer — Current Thinking.** We walked through the document with a lead comparing two proposals for the content workflow. The reviewer started from the artist time and build time measured separately, then followed the work to the point where another person would rely on it. The awkward case was a faster export that leaves every recipient to repair the imported package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated. **Handover exercise for Multiplayer — Current Thinking.** We walked through the document with an artist passing a work-in-progress asset to a technical designer. The reviewer started from the source file revision and the intended scene placement, then followed the work to the point where another person would rely on it. The awkward case was an exported asset being mistaken for the editable original. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete. **Provenance exercise for Multiplayer — Current Thinking.** We walked through the document with a programmer comparing a capture with a designer annotation. The reviewer started from the seed, build identity and camera location of the captured scene, then followed the work to the point where another person would rely on it. The awkward case was a visual comparison made from scenes generated by different builds. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream. **Permissions exercise for Multiplayer — Current Thinking.** We walked through the document with an external contributor delivering a package through the asset portal. The reviewer started from the permitted upload destination and the ownership of the source material, then followed the work to the point where another person would rely on it. The awkward case was a package containing reference images whose rights are not recorded. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives. ## DOC: Art Direction — Reference and Principles The world should feel like somewhere that has weather and history, not a generated surface. Principles: 1. **Silhouette first.** A ridge line should be readable from a distance as a shape with character. 2. **Evidence of process.** Scree below a cliff, deposition where a river slows, snow on the lee side. The player does not need to know why it looks right. 3. **Negative space.** Not everything should be interesting. Dull stretches make the interesting parts land. 4. **No repeating landmarks.** If a player sees the same distinctive rock twice, the illusion breaks harder than any amount of visible tiling. Palette is deliberately desaturated at distance with saturation increasing near the camera. This is not physically motivated, it just reads better. --- ### Operational review notebook **Review exercise for Art Direction — Reference and Principles.** We walked through the document with a lead comparing two proposals for the content workflow. The reviewer started from the artist time and build time measured separately, then followed the work to the point where another person would rely on it. The awkward case was a faster export that leaves every recipient to repair the imported package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated. **Handover exercise for Art Direction — Reference and Principles.** We walked through the document with an artist passing a work-in-progress asset to a technical designer. The reviewer started from the source file revision and the intended scene placement, then followed the work to the point where another person would rely on it. The awkward case was an exported asset being mistaken for the editable original. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete. **Provenance exercise for Art Direction — Reference and Principles.** We walked through the document with a programmer comparing a capture with a designer annotation. The reviewer started from the seed, build identity and camera location of the captured scene, then followed the work to the point where another person would rely on it. The awkward case was a visual comparison made from scenes generated by different builds. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream. **Permissions exercise for Art Direction — Reference and Principles.** We walked through the document with an external contributor delivering a package through the asset portal. The reviewer started from the permitted upload destination and the ownership of the source material, then followed the work to the point where another person would rely on it. The awkward case was a package containing reference images whose rights are not recorded. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives. **Exceptions exercise for Art Direction — Reference and Principles.** We walked through the document with a build engineer isolating a corrupt optional asset. The reviewer started from the asset identifier and a small reproducible fixture, then followed the work to the point where another person would rely on it. The awkward case was an unrelated missing texture obscuring the actual geometry defect. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion. ## DOC: Build and Release Process Builds run on every merge to main. A full build including all platform targets takes 34 minutes. Pipeline: 1. Compile (8 min) 2. Unit tests (3 min) 3. Determinism golden test (6 min) — generates 200 chunks and compares hashes 4. Asset cook (11 min) 5. Package per platform (6 min, parallel) The determinism test is the one that fails most often, almost always because someone introduced non-determinism without realizing. It is also the one people most want to skip when they are in a hurry, and we have agreed it is never skipped. Nightly builds additionally run a soak test: generate 50,000 chunks and watch for memory growth and timing drift. Caught a leak in the scatter allocator that unit tests would never have found. --- ### Operational review notebook **Handover exercise for Build and Release Process.** We walked through the document with an artist passing a work-in-progress asset to a technical designer. The reviewer started from the source file revision and the intended scene placement, then followed the work to the point where another person would rely on it. The awkward case was an exported asset being mistaken for the editable original. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete. **Provenance exercise for Build and Release Process.** We walked through the document with a programmer comparing a capture with a designer annotation. The reviewer started from the seed, build identity and camera location of the captured scene, then followed the work to the point where another person would rely on it. The awkward case was a visual comparison made from scenes generated by different builds. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream. **Permissions exercise for Build and Release Process.** We walked through the document with an external contributor delivering a package through the asset portal. The reviewer started from the permitted upload destination and the ownership of the source material, then followed the work to the point where another person would rely on it. The awkward case was a package containing reference images whose rights are not recorded. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives. **Exceptions exercise for Build and Release Process.** We walked through the document with a build engineer isolating a corrupt optional asset. The reviewer started from the asset identifier and a small reproducible fixture, then followed the work to the point where another person would rely on it. The awkward case was an unrelated missing texture obscuring the actual geometry defect. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion. **Rehearsal exercise for Build and Release Process.** We walked through the document with a producer arranging a playtest without unfinished campaign content. The reviewer started from a dedicated test save and a known starting scene, then followed the work to the point where another person would rely on it. The awkward case was a tester importing an old local save and describing it as a fresh game. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally. ## DOC: Playtest Round 4 — Findings Eight participants, two hours each, think-aloud protocol. **Terrain reads well.** Nobody described the world as generated or repetitive, which is the main thing we were testing. Two participants independently used the word "real". **Navigation is hard.** Six of eight got lost. The world lacks landmarks at the right scale — there are mountains visible from far away and detail at close range, but nothing at the middle distance that helps you orient. This is a real problem and the fix is probably more about placement than generation. **Rivers are beloved.** Five participants followed a river for extended periods without being asked to. Worth leaning into. **Scatter density in scrub biome felt wrong** to three participants, described variously as "patchy" and "like it didn't finish loading". Our radius there may be mismatched with object size. **Performance complaint** from one participant on an older machine, specifically stutter when moving fast, which is chunk streaming not keeping up. --- ### Operational review notebook **Provenance exercise for Playtest Round 4 — Findings.** We walked through the document with a programmer comparing a capture with a designer annotation. The reviewer started from the seed, build identity and camera location of the captured scene, then followed the work to the point where another person would rely on it. The awkward case was a visual comparison made from scenes generated by different builds. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream. **Permissions exercise for Playtest Round 4 — Findings.** We walked through the document with an external contributor delivering a package through the asset portal. The reviewer started from the permitted upload destination and the ownership of the source material, then followed the work to the point where another person would rely on it. The awkward case was a package containing reference images whose rights are not recorded. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives. **Exceptions exercise for Playtest Round 4 — Findings.** We walked through the document with a build engineer isolating a corrupt optional asset. The reviewer started from the asset identifier and a small reproducible fixture, then followed the work to the point where another person would rely on it. The awkward case was an unrelated missing texture obscuring the actual geometry defect. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion. **Rehearsal exercise for Playtest Round 4 — Findings.** We walked through the document with a producer arranging a playtest without unfinished campaign content. The reviewer started from a dedicated test save and a known starting scene, then followed the work to the point where another person would rely on it. The awkward case was a tester importing an old local save and describing it as a fresh game. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally. **Archiving exercise for Playtest Round 4 — Findings.** We walked through the document with a technical artist retiring a superseded material library. The reviewer started from the source graph revision and the export manifest, then followed the work to the point where another person would rely on it. The awkward case was a cached thumbnail showing a material that is no longer in the package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it. ## DOC: Scratch — terrain team - try the coarse flow field for hydrology, it is the only idea left that might get us under 12ms - scrub radius: 2.1 might be too big for the object sizes we actually use there, check - the golden test takes 6 minutes and 200 chunks might be more than we need for confidence, but reducing it feels like asking for trouble - someone should document why sediment capacity is 3.2 beyond "it looked right" - the 41MB save from the mountain-flattening player — is that a bug or just a person doing a thing - middle-distance landmarks: talk to art, this is their problem more than ours ### Operational review notebook **Permissions exercise for Scratch — terrain team.** We walked through the document with an external contributor delivering a package through the asset portal. The reviewer started from the permitted upload destination and the ownership of the source material, then followed the work to the point where another person would rely on it. The awkward case was a package containing reference images whose rights are not recorded. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives. **Exceptions exercise for Scratch — terrain team.** We walked through the document with a build engineer isolating a corrupt optional asset. The reviewer started from the asset identifier and a small reproducible fixture, then followed the work to the point where another person would rely on it. The awkward case was an unrelated missing texture obscuring the actual geometry defect. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion. **Rehearsal exercise for Scratch — terrain team.** We walked through the document with a producer arranging a playtest without unfinished campaign content. The reviewer started from a dedicated test save and a known starting scene, then followed the work to the point where another person would rely on it. The awkward case was a tester importing an old local save and describing it as a fresh game. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally. **Archiving exercise for Scratch — terrain team.** We walked through the document with a technical artist retiring a superseded material library. The reviewer started from the source graph revision and the export manifest, then followed the work to the point where another person would rely on it. The awkward case was a cached thumbnail showing a material that is no longer in the package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it. **Accessibility exercise for Scratch — terrain team.** We walked through the document with a player changing contrast and motion settings. The reviewer started from the resulting on-screen state rather than the position of a slider, then followed the work to the point where another person would rely on it. The awkward case was an interface preserving the slider while losing its effect after a scene change. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe. ## DOC: Audio Asset Packaging Working note for the next operations review. This document concerns its named workstream; it does not revise settings in other documents. ### Operational review notebook **Exceptions exercise for Audio Asset Packaging.** We walked through the document with a build engineer isolating a corrupt optional asset. The reviewer started from the asset identifier and a small reproducible fixture, then followed the work to the point where another person would rely on it. The awkward case was an unrelated missing texture obscuring the actual geometry defect. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion. **Rehearsal exercise for Audio Asset Packaging.** We walked through the document with a producer arranging a playtest without unfinished campaign content. The reviewer started from a dedicated test save and a known starting scene, then followed the work to the point where another person would rely on it. The awkward case was a tester importing an old local save and describing it as a fresh game. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally. **Archiving exercise for Audio Asset Packaging.** We walked through the document with a technical artist retiring a superseded material library. The reviewer started from the source graph revision and the export manifest, then followed the work to the point where another person would rely on it. The awkward case was a cached thumbnail showing a material that is no longer in the package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it. **Accessibility exercise for Audio Asset Packaging.** We walked through the document with a player changing contrast and motion settings. The reviewer started from the resulting on-screen state rather than the position of a slider, then followed the work to the point where another person would rely on it. The awkward case was an interface preserving the slider while losing its effect after a scene change. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe. **Review exercise for Audio Asset Packaging.** We walked through the document with a lead comparing two proposals for the content workflow. The reviewer started from the artist time and build time measured separately, then followed the work to the point where another person would rely on it. The awkward case was a faster export that leaves every recipient to repair the imported package. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room. We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated.