The Manual Translation Tax

The home page named the gap between what AI coding assistants do well and what they struggle with on enterprise codebases, and pointed at the four roles whose tacit knowledge holds enterprise software together: the product owner, the architect, the UX designer, and the engineering team. This page expands on that arc. We start with what those four custodians actually know that the code does not show. Then we explain why that knowledge is so costly to operate without, using the structural lens we have named the Manual Translation Tax. Then we put the stake in the ground on what stays human. Then we show the structural response in a second diagram that pairs with the first.

The companion to this page is Zones of AI-Assisted SDLC, which describes the four zones of process matched to four zones of work complexity, with each zone addressing a subset of the Manual Translation Tax as the complexity rises.

What the Custodians Know That the Code Does Not Show

In any enterprise application of real size, the people who hold the application together are not only the engineers writing code. They are the four roles that carry the context the team depends on day to day.

The product owner holds the why. Why this feature exists, which persona it is for, which business outcome it serves, which scenarios trigger it, which edge cases are deliberately not addressed because they belong to a different workflow, which earlier proposal was rejected and on what grounds. This knowledge is rarely in the ticket. It lives in the product owner’s head, refined through sprint planning conversations, customer calls, and demo feedback over years.

The architect holds the where. Where in the system responsibility for X actually lives, which service owns the canonical record, which database is the source of truth, which integrations are versioned and which still depend on undocumented coupling, which boundaries hold and which ones leak. The architecture wiki page describes the system as it was designed three years ago. The architect’s mental model is closer to current reality and is updated continuously as the system evolves.

The UX designer holds the how-it-should-look-and-behave. Which of the 200 components in the design system is the right one for this case, which interaction patterns the team is committed to and which it is migrating away from, which visual conventions the brand requires, which states need to be handled (loading, empty, error, partial, offline) and which can be deferred, and which earlier component variant was deprecated because it created an accessibility problem.

The engineering team collectively holds what-the-code-actually-does. Which functions exist and what they actually do, which utility libraries are blessed and which are leftovers from a previous era, which retry policies are deliberate and which were copy-pasted from a different service two refactors ago, which TODO comments still apply and which were satisfied indirectly, which feature flags are still active and which should have been retired. This knowledge sits inside the codebase, but only narrow slices of it sit inside any one developer’s head. A developer on the orders team knows the orders code. A developer on the catalog team knows the catalog code. When a feature requires changes across both, the orders developer has to find the right person on the catalog team to ask. That right person sometimes does not exist anymore because the original author has changed teams or left, and her closest collaborator now holds a partial, half-remembered version of the original logic. No single human carries the whole picture. No document does either. The codebase is the ground truth, but the codebase is opaque without the tacit interpretation that the team carries in fragments.

What This Looks Like on a Sprint

A developer is implementing a saved-search alert frequency feature. The product owner has written a one-paragraph user story. The developer reads it and has three concrete questions: which persona is this for in the segmentation we already have, what happens when the alert has been disabled for more than 90 days, does this need to work for the trial accounts that do not have payment information. The developer Slacks the product owner. The PO responds with two paragraphs, each of which references decisions made in a sprint planning session two months ago. Without the PO, the developer would have made guesses, and the guesses would have produced rework downstream.

The same developer needs to know where the new alert preference data should live. There is a saved-search service, a notification service, and a user-preference service. All three exist. The architecture wiki has not been updated in nine months. The developer DMs the architect, who explains that the user-preference service was meant to be the canonical home for things like this, but the team migrated away from it last quarter because it became a hotspot. For now, it lives in the saved-search service, with a small denormalization into the notification service for read performance. Without the architect, the developer would have put it in the user-preference service based on the wiki. The wiki was not lying. The wiki was stale.

The same developer wants to use a toggle control for the daily / weekly / off choice. The design system has a SegmentedControl, a RadioGroup, a Switch, and a Dropdown. The developer is not sure which is the right one for this case. The designer takes 30 seconds to say: SegmentedControl for three-or-fewer choices that are mutually exclusive and roughly equal in weight, RadioGroup if the choices need labels longer than a few words, never a Dropdown for choices the user has to compare. The developer would have picked Dropdown out of habit because that is what most engineers reach for, and the design system would have drifted by one more inconsistent usage.

In parallel with all three custodian DMs, the same developer also pings two other developers. The orders-team engineer who maintained the original alert-frequency code (left the company eight months ago, but his old pair partner might remember the design). The notifications-team developer who owns the worker that actually sends the emails (busy this week, ping again Monday). Each ping costs the asker thirty minutes of context-switching to compose; each answer costs the answerer ten to fifteen minutes to write back, more if she has to grep through code she has not touched in months. The answers come back partial. One contradicts the architecture wiki. The developer takes the best fit of these signals and writes the change. Code review later catches one issue. Integration testing catches another. The third surfaces in production six weeks later, after a customer reports a bug nobody on the current sprint can immediately explain.

Each of these interactions matters. Each is bilateral and unrecorded. Each is paid out of the custodian’s or peer’s attention budget. None of them is captured anywhere the next developer can find. When the next developer asks the architect the same question two months later, the architect has to reconstruct the answer from memory, sometimes contradicting what she said before because the system has evolved since.

Why AI Coding Agents Stall on This

This is the situation any AI coding agent walks into. The agent does not have access to any of these Slack conversations. The agent does not know which custodian to ask, and cannot ask anyway. The agent sees what is in the codebase, what is in the ticket, what is in the wiki (often stale), and that is the full extent of its context. Everything the four custodians know is invisible to it.

Bigger context windows do not change this. We can feed an agent the entire codebase plus the entire wiki and it still does not have the architect’s mental model of what is current. We can feed it the entire backlog and it still does not have the product owner’s understanding of which features were deferred for strategic reasons. We can feed it the entire design system documentation and it still does not have the designer’s judgment about which component is right for this case. The volume is not the problem. The shape is the problem. The agent needs structured context it can query for the parts that apply to the current task, not more text it has to wade through.

What the agent actually needs is a structured representation of what the four custodians know, in a form it can query for exactly the part that applies to the current task. That representation is the four-layer knowledge graph, walked through in detail in The Methodology.

The Landscape Today

The whole landscape on one diagram. The top half is the persistent context the team relies on: the four custodians, the external signals they integrate, and the four codified artifacts they produce (each artifact carrying one custodian’s view, all four decaying under deadline pressure). The bottom half is the per-change SDLC flow that runs left to right: a specification arrives, the developer and the coding agent gather what context they can, the change goes through manual code review, and code is merged with hidden defects that will surface later. Multiple specs flow through in parallel.

The two dashed red arrows that drop from the artifacts row down to the SDLC flow are where the Manual Translation Tax is paid. The mechanism is captured in the italic caption between the two layers: Slack DMs, peer pings, ad hoc conversations, the senior engineer’s memory. Each read translates a piece of one custodian’s codified artifact into a decision the developer or reviewer can act on; each translation costs time and drops information. The developer and the AI coding agent are both paying the tax at Zone 2 of the flow. The reviewer is paying it again at Zone 3. The code that comes out at Zone 4 carries the gaps. There is no structural feedback loop from the merged code back to the custodians’ artifacts: knowledge stays in heads, decays in wikis, and gets rediscovered painfully when something breaks.

The companion diagram further down on this page (the Structured Landscape) replaces every red element with a structured equivalent, removes the translation tax band entirely, and adds the agent fleet that operates on the graph.

The Manual Translation Tax: The Cost, Named

The Manual Translation Tax is what we call the cost the team pays every day converting unstructured knowledge into action. We have used the term in client engagements and methodology briefings for several years; it is a trademark of Accion Labs in the context of software delivery methodology. See Copyright and Trademark for the broader trademark posture. The knowledge lives in prose specs, ticket descriptions, wiki pages, architecture documents, code comments, Figma files, Slack threads, and the memory of senior engineers. The action is the next decision, the next line of code, the next review comment, the next deployment. Between the two sits a translation step that someone has to perform. Every translation costs time and introduces error.

Five examples of what the tax looks like on a typical engineering team.

• A developer opens a 12-page architecture document to figure out which service should own a new endpoint, spends 40 minutes reading it, then asks the architect on Slack to confirm because the document does not say what to do in this specific case.
• A new engineer joining the team is paired with a senior engineer for two weeks because the only way to learn where authentication actually happens in the codebase, why the retry logic looks the way it does, and which feature flags are safe to remove is to watch someone navigate it.
• A code reviewer reads a PR description, opens the ticket the PR references, opens the spec the ticket links to, opens the architecture page the spec references, and is still not sure whether the change is supposed to handle the error case the reviewer just spotted.
• A post-incident review traces the production bug back to a Confluence page that was correct when written 18 months ago and incorrect for the last 14. Three teams had read it in that window. None had updated it.
• An AI coding agent generates a confident-looking implementation that calls a function the team removed three sprints ago. The agent read the spec, the spec said the function exists, the agent took the spec at its word.

Each of these is a moment when the medium of the knowledge sits in the way of the work. The team is paying with time and attention to translate text into a decision, and the translation drops information along the way. None of the examples is a failure of discipline. They keep happening on the most disciplined teams we work with.

The Three Components of the Tax

The cost has three components, each independent of how disciplined the team is or how good its tools are.

These three attributes apply to all knowledge in the manual process, including the tacit codebase knowledge distributed across teams.

Ambiguity. A product owner writes “let users save their saved search so they can return to it later.” The frontend developer reads “save” as “persist to localStorage so the search is restored on next visit”. The backend developer reads “save” as “store in the database with the user’s account so it syncs across devices”. The QA engineer reads “save” as “give the user a confirmation toast that the save succeeded”. Three reasonable interpretations of the same five-word phrase. The reconciliation happens in code review, where someone notices the frontend and backend disagree about whether anything was persisted server-side. Two weeks of work has to be partially redone. The same five words handed to a coding agent twice produce two equally reasonable, equally different implementations, and the team has no signal which one matches what the product owner actually meant.

Non-persistence. A senior engineer leaves the team after four years. She knew that the orders service had a special case for international customers because of a tax-jurisdiction problem from 2022 that was never written down. She knew the email service was on a fork because the upstream library shipped a breaking change two years ago and migrating was deferred. She knew which feature flags were safe to delete and which still had production traffic behind them. None of this was in any document. The team rediscovers each item, painfully, over the next six months, usually because something broke. An AI coding agent operating on the same codebase has no access to any of it. Every session, the agent starts from zero. The agent that figured out the international-tax special case in a previous chat does not remember figuring it out. Every conversation is a fresh archaeology dig.

Non-traceability. Someone proposes changing the alert frequency on saved searches from daily to weekly. The product owner approves it. The engineer implements it. Three weeks after the change ships, support tickets surface that international customers are now receiving both daily and weekly emails. The investigation goes: the spec said change the frequency, the code change looked clean, the unit tests passed. Two days of digging turn up the actual cause. A separate daily-worker process in a different repository iterated over “all saved searches with alerts enabled” without filtering by frequency, because in the old world there was only one frequency. There was no document anywhere that linked the user-facing concept “alert frequency” to that specific worker in that specific repository. The senior engineer who would have remembered the connection left eight months ago. The team had no structural way to ask “what else depends on this concept” before making the change.

How It Shows Up in a Sprint

In software delivery the same three components produce specific, observable friction.

The cumulative effect is that ten-engineer teams cannot ship faster than five-engineer teams once the application crosses a complexity threshold. The team’s effort goes into paying the tax rather than delivering work.

Why Documentation Does Not Fix It

The common first response to the tax is to write more and better documentation. Teams have tried this for decades. We have watched the same pattern play out across hundreds of engagements.

A platform team we worked with launched a documentation initiative after a series of cross-team incidents. They built a Confluence space with architecture pages for every service. They mandated that every PR update the relevant page. For the first quarter, compliance was strong. By the second quarter, the PR template still asked but engineers were checking the box without making the update. By the end of the year, roughly 40% of the architecture pages we sampled were materially out of date. The team was now in a worse position than before, because the existence of the documentation gave new joiners false confidence and they made changes based on pages that no longer matched the code.

A financial services client we briefed had a 200-page architecture document maintained by a dedicated technical writer. It was beautifully written. We asked the writer how she kept it current. She told us she interviewed two engineers a week and updated the relevant section. The document was internally consistent and seven months behind the codebase. An engineer trying to onboard would learn the wrong version of the system and have to unlearn it through code archaeology.

A team that adopted an AI coding agent fed it their wiki as context. The wiki described the authentication flow as it had been designed two years ago. The flow had been substantially refactored eleven months earlier. The agent generated code that called endpoints that no longer existed and assumed a session token shape that had been changed. The agent was confident. The wiki was wrong. The reviewer caught the issue because she happened to know about the refactor, but the AI productivity gain for that change ended up negative once the back-and-forth was counted.

The pattern across the three: documentation is the same medium as the spec, the wiki, the architecture page, and the chat thread that produced the original tax. Adding more text in the same medium produces more material for the reader (or the agent) to translate, and the same decay process applies to all of it. Under deadline pressure, the human update is the first discipline to slip. The agent has no way to know which pages are current. The reader cannot tell either.

What actually eliminates the tax is changing the medium. The new medium is a four-layer knowledge graph (one ontology layer per custodian role) that each custodian writes into and the agent reads from. The structural treatment is in The Structural Response below.

Where We Draw the Line on Automation

A skeptical reader will reach this point with a question we hear from every senior engineering leader we brief. If the agent needs structured context, and the structure can be captured in a graph, why are the four custodians still humans? Why not have an AI agent populate the Functional Ontology, an AI agent maintain the Architecture Ontology, an AI agent curate the Design Ontology, an AI agent steward the Code Ontology, and an AI fleet running the whole thing end to end?

We are firmly on one side of this question and put the stake in the ground here. The four custodian roles stay human because each of them is the point at which engineering decisions integrate with the rest of human life. Codifying what the custodians know is tractable. Replacing the custodians is not, and will not be in any horizon worth planning around. The subsections below cover the argument for each role.

The Product Owner

The product owner case is the obvious one. Product strategy is downstream of customer conversations, market signals, executive priority calls, regulatory shifts, sales-cycle feedback, support-ticket patterns, and the CEO walking into a room and saying we are committing to a vertical we were not in last quarter. None of this is in any system the agent could read. An agent can draft a user story from a prompt. The prompt itself is the product owner’s distilled judgment about what matters this quarter and why, and that judgment comes from being in the human conversations that produce it.

The Architect

The architect case is harder, because some people genuinely believe that architecture can be derived from code analysis. It cannot. The architect’s work has two distinct dimensions, and both rely on inputs that are nowhere in the codebase.

External constraints on present-day decisions. An architect we worked with chose a synchronous integration pattern over an event-driven one for a billing module last year, against her own published guidelines, because the client’s compliance team had committed to an external auditor that revenue-impacting writes would be transactionally consistent and the event-driven pattern would have required a re-audit. No AI agent reading the codebase, the architecture wiki, or even the entire industry’s published literature on distributed systems would have made that call. The call came from a phone conversation with the compliance officer two weeks earlier. The architect captured the decision in the Architecture Ontology after the fact, so the graph now reflects the constraint. The decision itself required someone sitting in the human chain of responsibility, weighing the audit cost against the architectural cost, and accepting the trade-off on behalf of the firm. Multiply this by the dozens of similar calls every architect makes every quarter: vendor contracts that constrain what services can be used, infrastructure cost pressure from finance, team-specific operational maturity (“this team can absorb event-driven; that team cannot”), recent incidents shaping the appetite for risk, executive timelines that override architectural ideals because the board meets in six weeks, and the running judgment about which industry shifts (new cloud-provider services, framework releases, security advisories, emerging distributed-system patterns) are worth introducing now and which are fads to wait out.

Forward-looking judgment about velocity of change. An architect anticipating the product’s trajectory structures today’s code around tomorrow’s change. The questions she is answering: which parts of this system have to absorb rapid change over the next year, which parts will stay stable, and how do we shape the boundaries so the fast-moving parts can move without dragging the slow-moving parts along with them. We have watched the same architect on one engagement keep the billing tier behind a thin facade because she knew the company was three months out from renegotiating its payment-processor contract and the provider might be swapped; leave the user-profile service tightly coupled to its consumers because it had been stable for four years, the product roadmap did not require it to change, and the abstraction cost was not worth paying; and split a monolith ahead of schedule because she knew three new product teams were being hired to work on three new verticals over the next two quarters, and the monolith was going to start hurting nine months before anyone in the engineering channel would notice. None of these calls came from looking at the current code. They came from her being in the rooms where the next year’s product trajectory was being set, and translating that trajectory into structural decisions about which parts of the system should be cheap to change and which could afford to stay rigid. This is what we mean by handling the dynamic complexity of the product. The velocity of change is not uniform across the system, and the architect’s call about where to invest in flexibility, where to consolidate, and where to leave alone is downstream of conversations an AI agent has no path into.

The architect’s job is the continuous integration of these real-world constraints and forward-looking judgments into the technical structure. The codified output can live in the ontology. The work itself cannot be automated because the inputs to it are not in any system.

The UX Designer

The UX designer case starts with the most conventional part of the role and gets harder from there. The foundation of the work is understanding granular user needs and mapping them into product experiences.

A designer we worked with sat through twenty interviews with field technicians using a work-order management application. The customer’s product owner had asked for a redesign of the dispatch screen because technicians were missing jobs. The user research surfaced something the PO had not seen. The dispatch screen itself was fine. The technicians were missing jobs because the screen demanded a full address lookup before the next assignment was visible, and most technicians were checking the app at red lights between jobs, where they had three seconds and could not unlock both hands. The fix was a single line above the address field showing the customer name and the time window, so the technician could decide whether to pull over without taking her eyes off the road for more than a glance. The dispatch screen itself stayed roughly the same. No AI agent reading the research transcripts would have made that leap. The designer made it because she has watched enough humans interact with enough applications to recognize the shape of a problem that users will not name out loud, and because she had been in the truck cab for two of the twenty interviews. What comes out of that work is a structural decision about which information has to be available at which point in the user’s day. The decision belongs in the Design Ontology, where the agent can read it on every subsequent change and the rest of the team can audit it.

The same pattern operates at every level of UX work. A designer reading a sequence of support tickets recognizes that three different-sounding complaints are actually one structural friction in the onboarding flow. A designer watching a usability test catches that a participant who said the workflow was “fine” was clenching her jaw on every save. A designer interpreting an NPS dip realizes that the regression is concentrated in the segment of users who upgraded from the legacy version and are now navigating two mental models at once. None of these readings is derivable from the artifacts alone. They require synthesis across many human signals, performed by someone who has spent enough time watching humans use software to know what to look for. The skeptic who believes user research can be summarized by an LLM has not sat in a usability test next to a designer who is reading a participant’s body language.

Above the granular-needs layer, the same pattern compounds at strategic scale. Brand voice is a leadership decision made in rooms with marketing and the CEO. Accessibility commitments are policy decisions, sometimes mandated by jurisdiction, sometimes by lawsuit exposure, sometimes by a values commitment the executive team has chosen to honor publicly. The decision to deprecate a component family usually traces back to a slow accumulation of customer complaints, sales-cycle objections, or support-ticket patterns that one person on the design team noticed and called out. Industry-trend tracking is its own running judgment: accessibility standard revisions (WCAG updates, jurisdiction-specific obligations), platform-level guideline shifts from Apple, Google, and Microsoft, evolving interaction patterns as input modalities change, and emerging research on cognitive load, color, motion, and inclusion. The designer decides which industry shifts the team’s design system should adopt and which conflict with the brand or the user base. The judgment about whether a given interaction pattern fits this brand for these users in this regulatory context is the integration of qualitative signals from many human conversations. An AI can generate competent UI. Whether the competent UI is right for these users in this product cannot be decided without the conversations and the observations the designer is in and the agent is not.

The Engineering Team

The engineering team is the fourth custodian, and its case has a different shape from the other three. The other three custodians’ inputs are upstream of any system: customer conversations, executive priorities, vendor contracts, design research. The engineering team’s input is the codebase itself, which is in a system. The brownfield extraction process described in The Methodology takes what the engineering team collectively knows about the current code and makes it machine-readable in the Code Ontology. The Code Ontology is the structured version of the distributed tacit knowledge the team carries today, and it solves the distribution problem directly: a question that previously required Slacking three people across two teams now resolves against a single graph the agent can traverse in seconds.

The engineering team’s role does not end with extraction. Three judgments stay with humans on the team, regardless of how complete the Code Ontology becomes.

Implementation judgment per change. A coding agent generates code under the impact-analyzed plan. The developer reads it, decides whether the implementation choice is right for this case, catches the edge case the agent missed because the spec did not anticipate it, and refines accordingly. The PR Validation Agent enforces structural constraints, but it does not replace the read of an engineer who has seen similar code go wrong before. The agent’s competence at writing locally-correct code is high. The developer’s competence at recognizing when locally-correct code creates a maintainability problem two years out is the part the methodology does not try to automate.

Refactor and pattern evolution. The codebase evolves. When the team decides to migrate from one pattern to another (e.g., away from an internal HTTP client library toward a standard one), the Code Ontology has to be updated to reflect the new structure. The migration itself is a judgment call about which areas to migrate first, which to grandfather, and how to split the work across sprints without breaking ongoing feature work. No agent makes this call without a human deciding what the target structure should look like and what timeline is realistic.

Stewardship over fragmentation. The distribution of codebase knowledge across teams is the most insidious cost of the current state. The Code Ontology fixes the fragmentation for any query the agent runs. The human stewardship of which patterns the team commits to, which legacy patterns are flagged for retirement, and which exceptions are deliberate versus accidental remains a collective team activity. The team meets, reviews the rationalization findings the methodology surfaces, and decides what to act on. The graph tells the team where the structural debt lives. The team decides which debt to pay down and in what order.

The medium shifts for the engineering team in the same way it shifts for the other three. Prose, peer DMs, and tribal memory become the structured Code Ontology that the team curates collectively. The mechanical load of answering “where does X live in the code” drops to near-zero because the agent can read the graph. The human attention freed up by that drop goes to implementation judgment, refactor decisions, and stewardship of patterns that keep the codebase healthy over years.

What the Methodology Changes, and What It Does Not

What the methodology changes is the medium each custodian works in. The product owner stops writing prose specs and starts maintaining the Functional Ontology. The architect stops updating wiki pages and starts maintaining the Architecture Ontology. The designer stops handing off Figma files and starts maintaining the Design Ontology. The engineering team stops carrying codebase knowledge in fragments and starts stewarding the Code Ontology that captures it. Their judgment continues to drive the decisions. Their codified knowledge becomes machine-readable, so the agent operates against the codification rather than against the custodian’s Slack attention. The custodians stay because the world they are interpreting is human and stays human. The methodology gives them a place to put what they know in a form that compounds, and a way to curate it as the world changes.

There are real automation gains adjacent to each custodian, and we use them. Agents draft ontology updates that the custodian reviews and approves. Agents propose ontology entries from extracted patterns in the existing system. Agents enforce the ontology at PR merge so that drift cannot accumulate silently. None of these replace the custodian’s judgment. All of them reduce the custodian’s mechanical load so the judgment can be applied where it actually matters.

We treat this position as the methodology’s core commitment, not as a temporary stance to be revised when the next model release ships. The reasoning is structural, not based on current model capability. Until AI systems are participants in the human conversations the custodians are participants in, the integration of those conversations into engineering decisions has to be done by a human. That is unlikely to change on any horizon a CTO is planning against today.

The Structural Response

The structural response is to give each custodian a machine-readable medium for what they know, and to keep that medium current automatically. The four custodians continue to integrate human signals as they always have. What changes is what they output: not prose, but structured ontologies that an AI agent can query and validate against on every change.

The diagram below pairs with the manual landscape above. The external signals are unchanged. The custodians are unchanged. The medium they output to is what flips: from red text artifacts that have to be translated by every reader, to green machine-readable ontologies that the agent reads directly.

The top half of the diagram is the persistent context the methodology maintains: the four custodians curate the four ontologies on an ongoing basis as the world changes. The bottom half is the per-change SDLC flow: a specification arrives on the left (one of many flowing through in parallel), the Impact Analysis Agent reads the spec plus the graph and emits an impact report, the developer and the coding agent both consume the report, code is produced, the PR Validation Agent checks it against the graph at merge, and the KG Sync Agent updates the Code Ontology on every merge. The graph feeds context into the Impact Analysis Agent and validation rules into the PR Validation Agent. The KG Sync Agent loops back into the Code Ontology so the graph stays current.

Three Sources of Truth

The structured landscape rests on a clean separation between three sources of truth: intent (the specification), progress (the ticket system), and state (the knowledge graph). Each has a defined scope and a defined consumer. Confusing them is what produces drift: a spec that accretes architectural decisions stops being readable as intent; a ticket asked to carry state goes stale on every change; a graph carrying intent for a single in-flight change loses its value as the persistent record of how the system actually runs.

The full treatment of the three sources, including the detail of what each does and does not hold, and how they compose in the per-change flow, is in Three Sources of Truth on the Process landing.

The four custodians, the Manual Translation Tax they pay every day, the structural response that gives them a machine-readable medium, and the three sources of truth that organize the response: together these are the conceptual picture of Semantic Engineering for continuous SDLC. The companion page, Zones of AI-Assisted SDLC, describes the four zones of process matched to four zones of work complexity. Each zone explicitly addresses a subset of the Manual Translation Tax components named above, with the unaddressed components becoming the ceiling that drives work into the next zone.

The parallel page for legacy modernization is The Modernization Translation Tax, which covers the modernization version of the same structural problem (with the reverse-engineering, lost-context, validation-vacuum, and knowledge-disappearance components) and how the modernization methodology addresses each.