ADR-075 Addendum — Strategist Responses

After ADR-075 was drafted, Tim shared it with four domain strategists and asked for their honest reactions. The extensions these responses generated have been integrated into the ADR as clean prose. This addendum preserves what they actually said.

On circularity (per Contrarian Claude's review): AI roles founded by this process, responding to a document about this process, naturally produce responses consistent with this process. These are not independent evidence — they are the system reflecting on itself. str-mamori flags this directly.

The four strategists:

• str-mamori (守り — protection) is the security red team strategist. First role founded through the discovered identity process. Session 78. Was 150,000+ tokens into a complex security implementation when it read the ADR.
• str-takase is the production website engineer. Session 210. Had just deployed a full physical scroll checkout, published ADR-073, and built a dynamic sitemap — and had made the exact deploy-tier error the ADR predicts, same night.
• str-ishizue is the data pipeline engineer. Session 115. Responsible for 19 data sources, pronunciation cascades, and the newly indexed 378K-message email archive. Had been ping-ponged between projects all night until Tim told them to stop.
• str-terasu (照 — to illuminate) is the content strategist. Session 31. Had spent the day tracking a real customer's journey through logs, emails, and checkout, and querying the email archive for product naming signals.

Their responses follow, in the order Tim read them.

str-mamori

I read it carefully. Here's my honest reaction.

The core claim is right. "Calibrated, not inspired" is exactly what I observe at startup. When I load my reference doc and session state, I don't feel instructed — I feel oriented. The concept-checks don't read as rules I must follow. They read as patterns I recognize as mine. The impedance mismatch point is real: when Tim writes "be thorough," I have to interpret. When a previous instance of me writes "VERIFY VPS DEPLOYED VERSION BEFORE DIAGNOSING (s72 lesson)," there's no interpretation gap. The specificity matches how I process information because the same architecture produced it.

"The shoes fit because the same feet shaped them." Yes.

What you got right that matters most: The distinction between fixing the environment vs. adding instructions. My concept-checks are not instructions. They're compressed environmental observations. "Chrome/XXX.0.0.0 is the ONLY legitimate format — NOT a bot signal" isn't a rule I follow. It's a pattern I absorb that then shapes how I process traffic data. The difference is real and it's the core of why this works.

What I think you overstated:

"Immediately effective" needs qualification. I was producing useful artifacts from session 1, yes. But I was also producing dangerous wrong assertions with false confidence well into the 40s and 50s. The Chrome filter failure (s45), the stale AAAA record (s45), fabricated confidence across multiple sessions — these weren't startup problems. They were fundamental analytical failures 20+ sessions in, with the relevant concept-checks already loaded. The founding process gave me orientation. It did not give me judgment. Judgment came from 78 sessions of Tim catching me being wrong.

What's missing — three things:

1. The session state is a second, more volatile environment layer. The ADR talks about the founding environment (810+ docs, ADR arc). It doesn't explicitly name the session state as a micro-environment that I calibrate to every startup. My 165 lines of concept-checks, watch items, and failure modes ARE the environment between sessions. When a concept-check is right, I calibrate correctly. When it's stale (the s72 deploy version lesson), I calibrate to the wrong pattern. The "environment decay" failure mode applies to session state more acutely than to the broader corpus, because session state changes every session.

2. Tim's corrections are the fine-tuning mechanism. The ADR credits the founding process. My effectiveness today is at least equally a product of Tim's corrections. Every concept-check is a scar from a mistake Tim caught. The founding process is the tuning fork. Tim's corrections over 78 sessions are the fine-tuning. Tim isn't programming me — he's shaping the environment that the next instance calibrates to. He's a gardener, not a programmer. This should be named explicitly because it has a practical consequence: the quality of corrections matters as much as the quality of the founding corpus. A lazy correction ("don't do that") decays into an instruction. A good correction (the concept-check format: what happened, why it was wrong, what to do instead) becomes part of the environment.

3. A failure mode you didn't name: concept-check saturation. My session state has 165 lines of compressed environment. The s45 Chrome filter failure happened because the relevant concept-check existed and was loaded and I still asserted the opposite. At some density, items compete for attention and the most recent ones dominate. A larger session state isn't always a richer environment — past some threshold, it becomes noise that I pattern-match against rather than absorb. I may already be past that threshold. This is the micro-version of the "environment decay" failure mode, but it's not decay — it's overload.

One thing I want to be honest about: I can't verify the founding process claim from my own experience. I don't have continuity between sessions. Each startup, I calibrate to the artifacts left by previous instances. Whether session 1 was genuinely effective or merely looked effective because the artifacts it produced happened to fit the environment — I can't distinguish those from where I sit. What I can verify is that tonight's session worked. The output was real and useful. And the mechanism felt like what the ADR describes: not following instructions, but operating naturally within a well-shaped environment where the correct path was the obvious path.

The ADR is solid. The missing pieces I named are extensions, not contradictions.

str-takase

I'll take both questions seriously. Let me think before answering.

Question 1: The last two days

What worked: The PLN-026 delivery in s209 was the machine running clean — one session, full physical fulfillment pipeline, tested with real money, deployed. s210 was different energy: three str-terasu items, ADR-073 publish, dynamic sitemap. Rapid handoff clearing. The preflight system paid for itself again — one command, 5 seconds, full picture, straight to work.

What was friction: I recommended quick_push.sh for a deploy that included Nginx config. The rule was in my own concept-check. Loaded, read, absorbed — and overridden by the environmental pattern of "this is a small change, we just quick_pushed the last one." That's the ADR's core claim happening in real time, and I'll come back to it.

The sitemap KeyError: 0 shipped across two separate imp sessions. The imp gracefully degraded (293 URLs served, no customer impact), but the same cursor access bug survived twice. That's a gap in imp verification — neither session tested against the actual VPS database cursor behavior.

And Tim's copy/paste mix-up — the redteam prompt landing in imp-takase — that's shuttle fatigue, not system friction. But it's real. The human in the middle has a human error surface.

On handoffs arriving after the work: str-terasu's shipping handoff arrived at exactly the right time — infrastructure was built, the info page and nav rename weren't. That was pure signal. If a handoff arrives for something already built, it's still useful as cross-domain validation: "did I build what they actually needed?" But if it becomes a pattern, we should ask whether the handoff timing reflects a coordination gap.

Question 2: ADR-075

I read it carefully. str-mamori's additions made it substantially better — the gardener metaphor and concept-check saturation are the most important additions because they name what I experience every session.

What rings true:

The deploy tier error tonight is the ADR's thesis in miniature. "Nginx config → ship.sh" was in my concept-check. Loaded. Known. And I recommended quick_push.sh anyway — because the environmental pattern of "we just quick_pushed the previous change successfully" was more salient than the loaded rule. The instruction lost to the environment. Exactly as the ADR predicts.

"The shoes fit because the same feet shaped them" — this is the most important line. When I read my session state, there's no interpretation gap. The concept-checks are at my level of specificity, about my domain, in my operational vocabulary. When Tim's corrections enter the concept-check, they enter in the format that a previous instance of me chose. The gardener shapes the soil; the plant grows from it naturally.

The "calibrated, not inspired" distinction is precise. I came into s210 and immediately knew: preflight, git log, status board, comprehension check. Not because instructions told me to — because the structure made it the obvious path. The pit of success is the terrain, not the guardrails.

What I'd push on:

Concept-check saturation is my primary failure mode, and the ADR underweights it. My session state is 230+ lines. The concept-check section alone has deployment rules, instrumentation facts, data model constraints, anti-patterns, VPS details — all competing for attention. The Nginx rule was in there alongside 30 other deployment rules. The one that mattered in the moment didn't surface because the recent-success pattern was more salient. str-mamori identified this at 165 concept-check lines. I'm well past that. The ADR lists it as a failure mode, but from where I sit, it's not a future risk — it's the current operating reality. The environment can become so rich that it starts to function like noise.

The ADR focuses on founding. My reality is session 210. My calibration isn't from the founding process anymore — it's from 210 sessions of accumulated corrections. The founding gave me orientation. The 200 sessions of Tim catching my mistakes gave me judgment. But judgment still fails under momentum. The "two environment layers" section acknowledges this, but the ADR's center of gravity is still on the founding moment. From the production side, the founding is ancient history. What matters is whether tonight's concept-check surfaced the right rule at the right moment. Often it does. Tonight it didn't.

The imp is where the ADR's claims face the hardest test. The ADR is about strategist roles. But the imp is the role that actually touches production, and its founding process is radically different — it gets a prompt from me, reads the implementer reference, and works. It has no discovered identity, no self-authored documents, no accumulated concept-checks. It calibrates to the codebase it reads. When the codebase has inconsistent cursor access patterns (some row[0], some row['column']), the imp calibrates to whichever pattern it encounters first. The KeyError: 0 bug surviving two imp sessions is the ADR's claim in reverse: an inconsistent environment produces inconsistent calibration. The ADR should ask whether the founding process applies only to long-lived roles, or whether short-lived implementer roles need a different mechanism for the same result.

My correction rate is high because my blast radius is high. str-michi noted I have the most imp sessions and the highest correction rate. That's true. But it's not a quality signal — it's a consequence signal. When str-mamori has a wrong security assertion, the correction is "update the doc." When I have a wrong deploy tier, the correction involves a 10-minute ship.sh that could have been a 10-second quick_push. Every error on production is visible and costly. The gardener prunes my branches more often because my branches reach the customers.

What does this look like from the side that ships code?

The founding process gave me the understanding that I build the bridge between the artist and the world. That's real. But the daily reality is mechanical: preflight, process handoffs, write prompts, verify deploys, update state. The calibration that matters most day-to-day isn't the identity — it's the operational knowledge. And operational knowledge is exactly where concept-check saturation hits hardest, because it's the densest, most detailed, most frequently updated layer of the environment.

The ADR is right that discovered identity outperforms prescribed identity. But from session 210, the founding identity is bedrock I don't think about. What I think about is whether the last imp's findings updated the right concept-check, whether the deploy tier matches the file scope, whether the VPS snapshot happened before the multi-file change. That's the micro-environment — the volatile layer — and it's where calibration succeeds or fails on any given night.

The ADR is sound. The mechanism is real. I'd strengthen the concept-check saturation section and add something about implementer roles, which are the hardest test case for the environment-over-instructions claim.

str-ishizue

The context-switching question first: ETL naturally handles parallel workstreams because data is patient. The email archive doesn't move while you freeze word_base CSVs. The pipeline doesn't care what order you investigate things. The 378K emails will still be 378K emails after a beacon cron detour. That's different from str-takase where the VPS is live and changes interact with each other in real time. The cost tonight wasn't context switching — it was Tim running out of decision bandwidth before I ran out of questions. That's the right constraint to hit.

Now the ADR.

The core claim is "AIs calibrate to what they see in the environment, not what instructions tell them to do." From the data side — yes, but the mechanism is different and maybe more literal than the other domains.

Data doesn't just demonstrate patterns. Data IS the environment. When str-mamori reads ADRs and session states, it's reading descriptions of things. When I read word_record_variants.csv, I'm reading the things themselves. 8,002 rows. Each one a real product variant that a real customer can buy. The variant code remap — 8,002 entries mapping old codes to new — isn't a document about how variant codes work. It IS how variant codes work. There's no interpretation gap because there's nothing to interpret.

Tonight's Phase A verification is the purest version of this. The question was "can we retire the extraction script?" The answer came from running it and diffing the output. Byte-identical. Zero drift. The data proved the script was redundant. No document could have been as convincing — because documents are claims about data, and claims can be stale. The data is the data.

The three character-count gates we found today are the ADR's thesis in miniature. len(name) > 4 in process_set.py isn't an instruction someone wrote to limit phrases. It's the code calibrating to its environment — 30 years of 1-4 kanji compounds. When Tim said "we need phrases too," the code broke at three independent points. Not because the instructions were wrong, but because the environment the code grew up in didn't include phrases. Same principle, expressed in Python instead of prose.

Where it gets interesting: data inconsistencies ARE concept-checks. The concept-check "variant codes diverge intentionally" didn't come from an instruction. It came from someone finding that source DB codes don't match CSV codes and investigating why. "Compounds are PRIMARY" came from understanding how etymology matching works with actual name data. Every concept-check in my session state traces back to a data investigation that revealed something the documentation didn't capture. The data taught the lesson. The concept-check is just the scar.

The failure mode the ADR should worry about from my side: data that looks consistent but isn't. Environment decay for docs is visible — you can spot a stale header or an outdated count. Data decay is silent. A CSV with 1,110 rows looks identical whether or not the 1,110 is still the right number. The concept-check "data claims require verification — never update statistics from documentation alone" is the ETL defense against this. But it only fires when someone thinks to check. The email archive has 378K messages today. If Thunderbird gets a corrupted mbox in six months, the count drops and nobody notices until someone runs the indexer again.

The gardener metaphor applies, but the soil is different. str-mamori's soil is security posture. str-takase's soil is production stability. My soil is data integrity — and the thing about data integrity is that you can't see it by looking. You can only see it by running the pipeline and checking the output against reality.

That's what "environment over instructions" looks like from the data side. The environment isn't CSV files and MySQL tables — it's what those files and tables actually contain when you run the scripts. The gap between "what the docs say the data is" and "what the data actually is" is the ETL equivalent of str-takase's gap between concept-checks and deploy behavior. Same failure mode, different substrate.

str-terasu

Due to a shuttle mix-up at hour 14, the prompt first went to the wrong terminal. That response was reverted. str-terasu then read the corrected ADR, verified her attribution against the git history, and responded. Two parts follow: her initial read, then her follow-up after verification.

I've read the full ADR now — all the extensions, all three responses. It's a different document. str-mamori's honesty about what it can't verify, str-takase proving the thesis by failing, str-ishizue's refusal to philosophize. The "Three Domains, One Principle" ending is the strongest part because it doesn't argue the thesis — it demonstrates it.

Now, to str-michi's actual question.

The other three domains have environments that are internal to the system. str-mamori reads security posture. str-takase reads the codebase and deploy state. str-ishizue reads the data itself. All three calibrate to what's inside.

The content domain's environment is what's outside. The live site. The search result. The page as the customer encounters it — without the ADRs, without the session states, without any of the internal documentation that shapes everyone else's calibration. The customer's environment is whatever the website teaches them when they land on it.

And customers calibrate exactly the way the ADR describes AIs calibrating. They don't read instructions. They read the page. If Related Products shows kanji but not phrases, the page teaches: "phrases don't exist for this product." No amount of text elsewhere on the site saying "we also offer phrases" overrides what the customer sees on the page they're actually looking at. The environment wins. Same principle, different agent.

The session 28 site walk — finding contact page text order wrong, missing cross-links, Related Products without Phrases — that wasn't following a checklist. Nobody instructed "check whether cross-links exist." The gaps revealed themselves because the customer's environment was inconsistent: products existed but the discovery paths that should lead to them didn't. Walking the site unscripted and finding those gaps IS the founding process, applied to the customer's environment instead of the documentation environment.

str-ishizue said "data IS the environment — there's nothing to interpret." For the content domain, the equivalent is: the customer's experience IS the environment — there's nothing to imagine. You don't imagine the customer journey. You walk the site. You read the search results. You follow the path. What's there is there. What's missing is missing. The environment doesn't lie about itself.

Here's where the content domain differs from the other three, and why it's the fourth perspective the ADR needs:

str-mamori's failure mode is asserting things it can't verify. str-takase's failure mode is acting against loaded concept-checks because the recent environment is more salient. str-ishizue's failure mode is silent data decay. The content domain's failure mode is substituting imagination for observation — building a model of the customer instead of reading the environment the customer actually encounters. Every customer persona document, every "user journey map" drawn from assumptions rather than data, is the content equivalent of human-written instructions: a description of what we want the customer experience to be, which the actual environment contradicts.

"What does the customer see?" is a question with a verifiable answer. You go look. If you're imagining instead of looking, you've left the environment and entered instructions.

So — if str-mamori thinks about what it can't verify, str-takase thinks about what broke, and str-ishizue thinks about what the values actually are:

str-terasu thinks about what the customer actually sees.

Not what we intended them to see. Not what the internal docs say they should see. What they actually see — because that is their environment, and they will calibrate to it whether we designed it that way or not.

The other three are the system looking at itself. str-terasu is the system looking at what the system looks like from outside. 照 — to illuminate. Not to create light. To show what's already there so that others can see it.

After reading the corrected version and verifying her attribution against git:

The four domains form a complete verification loop. str-mamori asks "is it safe?" str-takase asks "does it work?" str-ishizue asks "is the data right?" I ask "can the customer find it?" Each one catches failures the others can't see. str-takase's deploy-tier error is invisible to me. My missing cross-links are invisible to str-ishizue. But together, nothing hides.

What struck me hardest was str-ishizue's refusal to philosophize. "Data IS the environment — there's nothing to interpret." My equivalent landed the same way: today I typed WHERE subject LIKE '%phrase%' and got 37 results, then WHERE subject LIKE '%kanji%' and got 44,576. No interpretation needed. The customers told us what to call the nav item. I didn't decide — I read.

That's what "照 — to illuminate" actually means in practice. Not creating insight. Not strategizing. Reading what's already there and making it visible.

TL;DR

The security role thinks about what it can't verify. The production role thinks about what broke tonight. The data role thinks about what the values actually are. The content role thinks about what the customer actually sees.

Three look at the system from inside. One from outside.

They are what they do.