True: An Open Methodology for AI-Native Software Delivery
Engineering judgment at AI speed. How any team can adopt it for free.
True is the discipline of keeping engineering judgment in charge of software production at AI speed. The methodology underneath True is called Continuous Integrity Delivery, or CID, and it is published as an open standard. This piece is that publication, written for sharing rather than for the binder.
A few things to say up front, because they shape everything that follows. True is free to adopt. There is no license fee, no certification gate, and no commercial relationship with any vendor required to operate under it. It is vendor-neutral and implementable with off-the-shelf tooling. No product is required. An organization that follows the rules of True is operating under True, regardless of the tools it uses to do so. The Guide is released under Creative Commons Attribution-ShareAlike 4.0, so you are free to adopt it, adapt it, and redistribute it with attribution.
A true process does not fold under stress. It absorbs it.
Why the name True
Like Agile, the word true carries many meanings. The methodology draws on a specific one.
To a bicycle mechanic, to true a wheel means to align it with the right tension so speed is maximized and momentum carries. Spoke tension, like the tension between people and organizations, cannot be too great or too loose. At either extreme the wheel collapses and folds. When a wheel is out of true, you feel it immediately. The bicycle wobbles, the rider corrects, and the energy that should have been forward motion is lost to the wobble.
Most of all, a true wheel is resilient under the stresses of the road. It does not avoid stress. It absorbs stress without losing its shape. A true wheel can hit the same pothole that destroys an out-of-true wheel and roll on.
True, the methodology, has the same objectives. It is the discipline of keeping AI-accelerated software systems properly tensioned across the components that pull against each other. It enables velocity without recklessness, efficiency without brittleness, and resilience without the fiction that failure can be prevented. When a system is out of true, the team feels it before they can name it, the same way a cyclist feels fatigue before realizing a wheel is wobbling. The discipline is in reading the tension and adjusting before the wobble turns to warping, and before the warping turns to collapse.
The metaphor is not decoration. It describes the operation the methodology performs. Engineers are the mechanics of their systems. AI is the wheel under load. CID is how the truing happens, the continuous integrity discipline that keeps the system aligned at speed. True is what the team is doing when they keep the wheel running clean.
Why True matters
Strip true down to its plainest definition and it means this: consistent with fact or reality, not false. That is the seed of the whole approach.
Too often, as engineering leaders, product leaders, and PMO leaders, we have watched software projects report all-green status, claiming an entire effort is perfect. It usually is not. This happens in organizations where the leaders who present honest status get publicly dressed down for not doing their jobs, when they should be celebrated for being true to their role and true to their company’s own transparency policies.
True exists so companies can celebrate the real state of their projects and have the genuinely difficult conversations that produce genuinely meaningful movement. The methodology does not make honest reporting comfortable. It makes honest reporting structurally required, and it gives the leaders who report honestly a framework that backs them when the conversation gets hard.
A True team is not one that never has problems. A True team is one whose problems are visible, named, and addressed before they compound. Transparency becomes an organizational attribute when safety is built structurally into the work, the same principle that gave the Toyota Way its enduring quality discipline.
What True is, and what it is not
True is a lightweight framework for delivering software in environments where AI participates materially in producing code, tests, configuration, and documentation. It treats intent and integrity as continuous properties of the system rather than a phase of delivery. By integrity we mean the alignment of intent, architecture, and authority across every change.
It rests on three observations.
First, AI shifts the bottleneck in software delivery from production to integration. Teams using AI generate code faster than they can reason about it, review it, and reconcile it with the existing system. The constraint is no longer typing speed. It is coherence at velocity.
Second, traditional Agile frameworks were designed around human execution speed and periodic coordination. They do not provide the continuous architectural, security, and authority controls that AI-driven change rates require.
Third, governance treated as documentation or as a release-gate ritual cannot keep pace with AI-driven change. Governance must be operational. It must live in the pipeline, the cadence, and the authority model. If it is not embedded there, it does not exist.
True responds with a six-domain continuous loop, five role accountabilities, four named cadences, three governance artifacts, and ten normative rules. The rest of this piece defines each in turn.
A word on what True is not. It is not a project methodology, a product, a tool, a certification scheme, or a replacement for engineering judgment. It is a way of organizing the work of human and AI teams so that integrity survives as the system changes. It does not tell you which tools to use, which languages to adopt, or which AI providers to choose. It tells you what must be true about the operating model regardless of those choices.
The theory: the integrity gap
Every AI-generated change is a unit of work that no human has fully reasoned through. That is not a defect of AI. It is the structural property that makes AI useful at scale. The cumulative effect, though, is code that compiles, passes tests, and ships, yet that no individual on the team fully understands. Without compensating discipline, this code piles up as architectural drift, semantic drift, and authority drift, faster than any human-paced review process can catch.
True names that gap and closes it with three moves.
Intent precedes generation. Every unit of work begins with structured, machine-consumable intent. AI generates against intent, not against ambiguity.
Validation is continuous, not phased. Architecture, security, and integration validation happen during generation, after generation, and after deployment. They do not wait for a single quality gate at the end.
Governance is runtime, not paperwork. Drift is measured continuously against defined tolerances. Authority is enforced as code. Evidence accumulates as a side effect of execution, not assembled after the fact for an audit.
True is empirical. It assumes the right answer to most engineering questions is not knowable in advance and must be discovered through observation, evidence, and adjustment. Plans, estimates, and architectural intentions are starting points, not commitments. The loop exists to surface the gap between intention and reality continuously, so the gap can be closed before it compounds. That empiricism shows up as three pillars: transparency (system state, drift signals, AI authorship, and authority decisions must be visible to everyone accountable, because hidden state is the most expensive defect class in AI-accelerated systems), inspection (artifacts and progress are inspected at named cadences, and inspection is about decisions, not status), and adaptation (when inspection shows something has drifted past tolerance, the responsible party adjusts the system, the process, or the intent without waiting for a planning ceremony).
The six-domain loop
True runs as a wheel of six domains, each in continuous tension with its neighbors. No domain is optional. No domain is a phase. All six are active at once across the life of any unit of work, and the system runs true only when each spoke holds its load against the others.
Why a wheel? Agile was iterative and incremental, and that goodness carries into True. The software lifecycle is continuous, not phased, and the wheel captures that continuity in a single image. The hub is small relative to the rim. That is deliberate: the work of decision-making and judgment needed to maintain intent integrity is smaller in volume than the work of producing all the artifacts, data, and information the agents distill into critical observations. The agents do the heavy work at the rim. The humans do the small, weighty work at the hub.
The hub matters for another reason. The bearings inside a real wheel hub run smoothest when the materials are highest quality, like ceramic races against polished steel. The bearings are the metaphor for the interaction between people, processes, and work products. Smooth bearings, smooth interactions. Rough bearings, and every revolution costs the wheel energy that should have gone into forward motion.
The spokes are drawn symmetrically to please the eye, but like all processes, the handshakes between humans and AI agents must be tuned to the organization and the tolerances of the market it serves. The wheel in this Guide is the standard pattern. The wheel in your shop will be trued to your conditions. You must not bend your organization to match the picture. You modify the picture to match your needs, no matter how ugly the spoke pattern turns out.
The six domains:
Intent, owned by the Product Manager. Define business intent, risk constraints, acceptance boundaries, and machine-consumable context for every unit of work. Outputs: a prioritized roadmap, policy constraints, structured acceptance criteria, and intent records.
Generate, owned by Engineers and AI together. Produce candidate changes rapidly through AI-assisted or AI-led generation, bounded by intent. Outputs: code, tests, configuration, design artifacts, documentation, and AI authorship metadata.
Validate, owned by Engineers and the System Architect. Check correctness, maintainability, security, and architectural alignment of every candidate, continuously. Outputs: validated candidates, exception records, defect findings, and architecture conformance verdicts.
Observe, owned by Platform and SRE. Capture ground truth from runtime behavior, deployments, and system topology. Outputs: telemetry, traces, dependency graphs, incident records, and usage signals.
Govern, owned by the System Architect and the policy engine. Measure drift, enforce authority boundaries, and preserve auditability across the system. Outputs: drift scores, authority decisions, gate verdicts, and audit records.
Adapt, owned by cross-functional leaders. Refine roadmap, constraints, prompts, controls, and architecture based on accumulated evidence.
Adapt is the only domain that does not run continuously. It runs in response to a defined trigger, and an organization adopting True must define those triggers. At minimum, two classes must be present. Evidence-based triggers fire when measurement shows the system has drifted out of bounds, or the same exception keeps recurring. Cadence-based triggers are the scheduled reviews, which must close with explicit decisions or explicit decisions to defer. Organizations in regulated, safety-critical, or capital-intensive settings will set narrower thresholds than those in lower-stakes contexts. The standard does not prescribe the thresholds. It requires that they exist, that they be documented, and that they be reviewed under the same change discipline as code.
The five roles
True defines five accountabilities. These are accountabilities, not job titles. One person may hold more than one role, and one role may be split across more than one person, but every accountability must have a single named owner at any moment.
The Product Manager is accountable for intent clarity and prioritization. The Product Manager owns the roadmap, decides priority and acceptance, and ensures every unit of work entering Generate carries machine-consumable intent. This role is full-time and continuously available. A part-time Product Owner is incompatible with the change rates True assumes.
The System Architect is accountable for architectural integrity and authority design. The role absorbs the control responsibilities historically given to the Scrum Master and adds explicit architectural authority. The System Architect owns the architecture rules, the defined tolerances, the authority scopes for human and AI actors alike, and the escalation path for boundary exceptions. This is the single accountable person for whether True is operating correctly inside the team. Process facilitation is still useful, but it is subordinate to architectural authority. A team operating without a System Architect is not operating under True.
Engineers are accountable for AI orchestration, integration, and review. They spend less time typing and more time framing intent for generation, validating and integrating AI-generated candidates, exercising judgment on architectural fit, and handling exceptions that fall outside automated controls. Engineers keep final accountability for every change that ships, whether a person or an agent produced the code.
Security and Platform are accountable for security posture and runtime operability. Under True these functions move earlier in the cycle and stay active after deployment. Static analysis before merge and dynamic or behavioral analysis after deploy are both required. AI-generated code must receive elevated security scrutiny relative to human-authored code, given the documented risk of plausible-but-insecure patterns.
AI Agents are accountable for accelerated candidate generation within bounded authority. Under True, agents are not passive assistants. They are bounded collaborators with explicit authority scopes, escalation paths, and intervention thresholds. Every agent active in the codebase must be identifiable, must operate within a defined authority scope, and must answer to a named human or governance authority. An agent that acts outside its scope must be detected, recorded, and intervened on as a first-class governance event. This is not optional configuration. An organization that lets agents act in the codebase without an explicit, recorded, enforced authority scope is not operating under True.
The four cadences
True defines four named cadences plus a quarterly review. Cadences are about decisions, not status. A cadence that produces no decisions, no adaptations, and no recorded outcomes is not a True cadence and should be retired.
The Morning Signal Review runs fifteen minutes. It focuses on overnight drift deltas, exceptions, security findings, dependency hotspots, and AI authorship anomalies. It is not a status meeting. Each item closes with an explicit decision: allow, review, or block. Items needing deeper work route to the Weekly Architecture and Drift Review.
The End-of-Day Alignment runs fifteen minutes. A brief cross-functional sync on blocking issues, authority escalations, and next-cycle intent clarification. It captures what cannot wait until the next morning.
Continuous Refinement is asynchronous. Roadmap shaping, acceptance clarification, and context updates happen continuously. There is no single grooming ceremony. The Product Manager is available for refinement throughout working hours.
The Weekly Architecture and Drift Review runs sixty minutes and is chaired by the System Architect. It is a deeper look at trend lines, systemic hotspots, recurring overrides, agent behavior, and places where tolerances may need recalibration. It closes with explicit decisions or explicit decisions to defer.
The Quarterly Standard Review runs a half-day. The team reviews its own CID operating model: what worked, what did not, which rules need local interpretation, which controls need investment, and whether the cadence calendar should change.
Every cadence should leave a short written artifact: a brief record of decisions made and items deferred. It does not need to be elaborate. It does need to exist, be discoverable, and link back to the drift signals or governance events that prompted each decision.
The three artifacts
Each artifact is operational, not ceremonial, and each carries enforceable consequences when its content changes.
The Roadmap is the governing prioritization artifact. It is a living statement of business intent, time-ordered constraints, and risk boundaries. Under True the Roadmap replaces the backlog as the primary planning artifact. A backlog still exists as a dynamic implementation surface derived from the Roadmap, but the backlog is not the unit of governance. The Roadmap is. At minimum it must express business goals with target windows, explicit risk constraints and policy obligations, named accountabilities for each goal, and an explicit acceptance bar for each goal. It must be visible to every accountable role.
The Intent Record is the structured, machine-consumable representation of a unit of work. Every unit of work entering Generate must carry one, and an Intent Record missing any required field must not be admitted to Generate. The minimum schema is six fields. The goal is a single plain-language sentence stating the outcome the work should produce, no more than 200 characters. The constraints are an explicit list of what the change must respect: regulatory obligations, performance bounds, compatibility requirements, security or privacy policies, data residency, dependency restrictions, one line each. The context points to the bounded context, services, modules, and domain terms relevant to the change, enough for an agent or a new engineer to find the work without asking. The acceptance is a set of verifiable, testable conditions sufficient to decide without ambiguity whether the change met its intent. The authority names the human or AI actor authorized to make the change, the authorities that may approve exceptions, and the escalation path for disputes. The ai_use field declares whether AI generation is permitted and at what scope, set to one of prohibited, advisory, generative-bounded, or generative-broad, with the default defined by team policy. The Intent Record may carry more fields. The schema above is the floor, not the ceiling, and the format (YAML, JSON, structured Markdown, ticket template) is the team’s choice as long as it is uniformly machine-readable.
The Audit Trail is the cumulative, immutable record of every governance-relevant event in the loop. It is the byproduct of True operating correctly, not something assembled afterward for compliance. At minimum it must capture every Intent Record creation and modification, every commit with AI authorship metadata, every gate decision (allow, review, block) with the rule that triggered it, every authority override with the human of record and the rationale, every drift score calculation with the inputs that produced it, and every Adapt-cycle decision linked to the trigger that prompted it. Records must be immutable, time-stamped, and identity-bound.
The ten rules of True
These rules are normative. An organization that does not enforce them is not operating under True, whatever language it uses to describe its process.
Intent must be machine-consumable. Every unit of work entering Generate must carry a complete Intent Record. Ambiguous free-text intent is incompatible with AI generation and is the most reliable predictor of downstream rework. Work that cannot be expressed as a machine-consumable Intent Record shall not be admitted to Generate.
The Roadmap replaces the backlog. The Roadmap governs prioritization. A backlog, where it exists, is a dynamic implementation surface derived from the Roadmap, not a static list managed as an end in itself. Teams that treat the backlog as authoritative are operating Agile, not True.
Generation is AI-first and human-guided. AI accelerates candidate generation. Humans keep responsibility for intent framing, critical judgment, integration discipline, and final accountability. A team that treats AI output as automatically acceptable is not operating under True. A team that refuses to use AI generation where the Intent Record permits it is also not operating under True. Refusal at the team level cannot override organizational policy.
Validation is continuous, not a phase. Functional testing, architecture conformance checks, security validation, and integration review must run during generation, after generation, and after deployment. Validation that runs only at a single end-of-cycle gate is incompatible with the change rates True assumes.
Architecture must be explicit and enforced. Boundaries, interfaces, ownership, and dependency rules must be documented and machine-checkable wherever technically feasible. Architecture rules that exist only as written guidance, with no automated enforcement, do not survive AI-driven change rates and shall be treated as advisory, not normative.
Governance runs at runtime. Policies are executable controls, not documentation. Runtime enforcement, deployment gates, and authority checks are structural parts of the SDLC. A True-conformant pipeline emits structured governance events at every stage. Ad hoc review checklists do not satisfy this rule.
Drift must be measured and managed against defined tolerances. Divergence between intended and emergent system state must be quantified, displayed, and compared against explicit tolerances. The objective is not zero drift. It is controlled drift within defined bounds. Tolerances must be versioned, signed, and reviewed under the same change discipline as code.
Authority must be explicit for every actor. Every actor, human or AI, must have a defined authority scope, escalation path, and intervention threshold. Agents acting in the codebase without an explicit, recorded, enforced authority scope are themselves an authority drift event and must be treated as one. Authority drift is a first-class risk category, equal in weight to structural and behavioral drift.
Auditability is non-negotiable. The system must preserve enough evidence to reconstruct significant decisions, approvals, exceptions, and execution paths after the fact, without depending on anyone’s memory. Evidence design must be specified before implementation begins. Retroactive auditability is incomplete by definition and incompatible with regulated environments.
Human intervention is exception-based. Humans should spend less time on routine status management and more on ambiguity resolution, high-impact decisions, exception handling, and system correction. A True team whose hours are dominated by ceremony, status reporting, or ticket grooming is not yet operating under True.
Drift, tolerance, and governance enforcement
Governance under True is the operating discipline that keeps the system aligned with intent as the system changes. It is not paperwork around the software process. It is part of the operating architecture.
True requires organizations to measure drift continuously. Drift is the divergence between the intended state of the system and the observed state, in any dimension that matters to the context. The standard does not prescribe a fixed taxonomy, because different organizations care about different dimensions. A regulated medical device firm cares about different drift than a high-frequency trading firm, and both differ from a multi-tenant SaaS firm. The standard requires that the organization name the dimensions it cares about, define how each is measured, and review the measurements continuously. At minimum, any organization claiming conformance must measure three: the divergence between intended and observed system structure, the divergence between expected and observed behavior, and the divergence between authorized and exercised authority. More may be added.
True assumes small amounts of drift are normal and expected. The objective is controlled drift within tolerances the organization has defined explicitly. For each dimension measured, a tolerance must distinguish acceptable variance from unacceptable variance, and that tolerance must be versioned configuration, reviewed under the same change discipline as code, and visible to every accountable role. How it is expressed is up to the implementing team. Some use simple thresholds, some use statistical control limits derived from historical baselines, some use risk-weighted tiering. The standard does not prescribe the form. It requires that tolerance exist, that it be explicit, and that it be enforceable.
Governance is enforced structurally; at the moment a change would otherwise enter the system. Documentation review, after-the-fact audit, and quarterly compliance ceremonies do not satisfy this. The enforcement point must run on every change, not periodically, and it must be able to stop a change from progressing when tolerances are exceeded. Whether that enforcement lives in the CI/CD pipeline as a programmatic gate, as a runtime control, or as both, is the organization’s call. The standard requires the function, not the form.
Authority and the override model
True treats authority as a structural property of the system. It is not implicit, not inherited, and not assumed. It is recorded, scoped, and enforced.
Every actor carries an explicit authority scope that must be defined, recorded, and enforceable. It must answer at least four questions: where the actor may act, what the actor may do, who the actor escalates to, and under what conditions the authority may be withdrawn. Authority scopes that exist only as written guidance are advisory and do not satisfy Rule 8. To be enforceable, a scope must be expressed in a form the governance layer can act on, not merely a form the team has agreed to honor.
Overrides are first-class governance events. Any decision to allow a change the enforcement layer would otherwise block, or to let an actor act outside their scope, is an override. True treats overrides as legitimate but expensive. They are permitted, but recorded, escalated, and reviewed. Every override must capture enough evidence that an outside reviewer, with no help from anyone who was in the room, can reconstruct what was overridden, who took responsibility, and why. An AI agent may not be the authority of record for an override. A human of record is required every time. Repeated overrides on the same rule are a defined Adapt-cycle trigger: the pattern means the rule is wrong, the tolerance is mis-calibrated, or the authority model is incomplete, all of which the Adapt domain can repair.
Auditability
Auditability under True is operational, not retrospective. The Audit Trail accumulates as a side effect of the loop running correctly. An organization that has to assemble its audit evidence after the fact is not operating under True.
The Audit Trail must let an outside reviewer, with no dependence on anyone’s memory, reconstruct what was intended (the Intent Record at the time work entered Generate), what was generated (commits, with AI authorship metadata where applicable), what was validated (test results, security findings, architecture conformance verdicts), what was decided (gate verdicts, authority overrides, exception approvals), what was deployed (a release record linked to the originating Intent Record), what was observed (post-deployment telemetry and incident records), and what was adapted (Adapt-cycle decisions and the triggers that prompted them).
Audit records must be durable, identity-bound, and reviewable. Durable means they cannot be silently altered or removed. Identity-bound means every record names the human or AI actor responsible. Reviewable means an outside party can examine the record without depending on the original team or on proprietary tooling. The technical form is the organization’s choice. The standard requires the properties, not the form. Auditability is what lets an organization defend its decisions to a regulator, a customer, an acquirer, or a court. Organizations under regimes such as SOC 2, ISO 27001, IEC 62304, FDA 21 CFR Part 11, the EU AI Act, or GDPR will have additional, jurisdiction-specific requirements that layer on top of the True floor. The standard does not replace those. It sets the baseline they sit on.
Implementing True
True is implementable across many kinds of organization using many kinds of tooling. The standard prescribes no reference architecture, no recommended pipeline structure, and no preferred vendors. Different organizations reach conformance by different paths, depending on their existing tooling, regulatory environment, scale, and engineering capacity.
Two broad paths are common. On the build path, an engineering organization assembles enforcement from existing components: its CI/CD platform, its static analysis suite, its security scanning tools, its observability stack, and its identity and access management. The build path takes real integration engineering and ongoing investment to maintain the enforcement layer, but it offers full control and avoids vendor dependency. Teams with mature platform engineering and complex regulatory requirements often choose it. On the buy path, the organization adopts a commercial governance platform that implements enforcement out of the box. That reduces integration burden and time-to-conformance but introduces a vendor relationship. Teams whose engineering capacity is fully committed to product, or whose regulatory horizon makes early conformance commercially valuable, often choose it. The standard takes no position on which is preferable. It defines what conformance looks like. How you get there is yours to decide.
The effort varies by starting position. An organization that already runs a modern CI/CD pipeline, has machine-checkable architecture rules, and keeps durable audit logging will reach conformance faster than one starting from a less mature platform. But True is not a tooling project. The bulk of the work is in the operating model: defining the Intent Record, naming the System Architect, establishing the cadence calendar, and committing to the discipline of refusing to admit work that does not carry a complete Intent Record. Tooling enables the discipline. It does not replace it. Expect the operating-model work to be the most expensive part of the transition, even though it requires no procurement. The tooling work is bounded and well understood. The discipline work is where the practice succeeds or fails.
Adopting True
True is designed to be adopted progressively. Do not attempt a full rollout in a single step. Begin with one team, establish the operating model and the supporting tooling, gather evidence about what works in your context, then roll the practice outward.
The most common starting point is to name the System Architect and adopt the Intent Record. Both moves cost nothing in tooling and immediately change how work flows. A team that has named its System Architect and is refusing to admit work without a complete Intent Record is already operating in the spirit of True, before any pipeline instrumentation exists.
From there, the cadence calendar is the next move. The Morning Signal Review and End-of-Day Alignment set the rhythm of decision-making. The Weekly Architecture and Drift Review builds the habit of stepping back to look at trends. The Quarterly Standard Review builds the habit of inspecting and adapting the operating model itself. Tooling investment follows the operating model, not the other way around. Teams that buy tooling before establishing the operating model often end up with a governance pipeline they never use, because the underlying disciplines were never adopted.
After the first team has run under True for a quarter, apply the lessons to a second team. After two quarters, a third. The standard does not set a pace. It requires that the rollout be evidence-led, not deadline-led.
Closing
True came from a single observation: AI is changing the rate at which software systems mutate, and traditional Agile frameworks were not built for that rate. The frameworks that worked at human typing speed do not preserve integrity at AI generation speed. Something else is required.
True is the simplest framework we could build that closes the gap. It is not the only possible answer. It is a working one, in the sense that teams operating under True preserve architectural integrity, security posture, and audit evidence at change rates that overwhelm Agile-only teams. The Guide will evolve as the practice accumulates. This version is the starting point.
The methodology is published as an open standard, Continuous Integrity Delivery, under Creative Commons Attribution-ShareAlike 4.0. Adopt it. Adapt it. Improve it. Contribute back what you learn. The framework is yours to use.
Glossary
Adapt. The True domain in which roadmap, constraints, controls, and architecture are revised based on accumulated evidence. Triggered by evidence-based and cadence-based events defined by the implementing organization.
Audit Trail. The immutable, time-stamped, identity-bound record of every governance-relevant event in the True loop. A required artifact.
Authority Drift. Divergence between the authority an actor is granted and the authority the actor exercises in practice. One of the drift dimensions True requires organizations to measure.
Authority Scope. The explicit, machine-readable record of what an actor (human or AI) may do, who they escalate to, and when their authority may be revoked.
Behavioral Drift. Divergence between expected and actual runtime behavior or execution paths.
CID. Continuous Integrity Delivery. The technical name of the methodology this Guide defines. The public-facing name for the discipline is True.
Continuous Refinement. The asynchronous activity in which roadmap shaping, acceptance clarification, and context updates happen on a continuous basis rather than in a single grooming ceremony.
Drift. Divergence between the intended state of the system and the observed state. Categorized as structural, behavioral, authority, or velocity mismatch.
End-of-Day Alignment. A fifteen-minute cadence focused on blocking issues, authority escalations, and next-cycle intent clarification.
Generate. The domain in which AI and humans produce candidate changes against an Intent Record.
Govern. The domain in which drift is measured, authority is enforced, and audit evidence is preserved.
Intent. The domain in which business intent, constraints, context, and acceptance criteria are recorded as a machine-consumable Intent Record.
Intent Record. The structured, machine-consumable representation of a unit of work. A required artifact. Minimum schema: goal, constraints, context, acceptance, authority, ai_use.
Morning Signal Review. A fifteen-minute cadence focused on overnight drift deltas, exceptions, security findings, dependency hotspots, and AI authorship anomalies.
Observe. The domain in which runtime behavior, deployments, and system topology are continuously captured.
Override. A first-class governance event in which a human of record permits a change or action the governance system would otherwise block. Recorded, escalated, and reviewed.
Product Manager. The role accountable for intent clarity and prioritization. Owns the Roadmap.
Quarterly Standard Review. A half-day cadence in which the team reviews its own True operating model and decides what to change.
Roadmap. The governing prioritization artifact under True. Replaces the backlog as the primary planning document.
Structural Drift. Divergence between intended architecture and observed dependency, service, or module topology.
System Architect. The role accountable for architectural integrity and authority design. Absorbs the control responsibilities historically allocated to the Scrum Master.
Tolerance. Versioned configuration that distinguishes acceptable variance from unacceptable variance for a measured drift dimension. Form is the implementing organization’s choice. Reviewed under the same change discipline as code.
True. The discipline of keeping engineering judgment in charge of software production at AI speed. The methodology underneath it is Continuous Integrity Delivery (CID).
Validate. The domain in which correctness, maintainability, security, and architectural alignment are checked continuously.
Velocity Mismatch. A drift category in which the change rate exceeds the team’s review, governance, or integration capacity. Usually a leading indicator of other drift categories.
Weekly Architecture and Drift Review. A sixty-minute cadence chaired by the System Architect, focused on trend lines, systemic hotspots, and tolerance recalibration.
The True Guide, v2, May 2026. Developed by Keith Willett, as a contribution to the engineering community. Licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). You are free to share and adapt it for any purpose, including commercial use, provided you give credit, indicate changes, and distribute derivative work under the same license. Comments, errata, and proposed revisions are welcome.
For companies looking to transition to being AI native, this is the high-level of a working model. There are a lot of decisions still to be made, but this gives you the framework a consulting company would sell to you.