1
Organize around knowledge throughput, not delivery capacity.
Follow the model from top to bottom. Tap any item for details.
The AI-Native Operating Model™
How an organization runs when execution is no longer the constraint. Click any element to drill into the detail.
Direction Intent Council & Flow Council
Execution Fleet Lead & agent fleet
Domain judgment Decision Owner & knowledge network
SINGULARICS
The AI-Native Operating Model™
Down from the Enterprise
Five inputs from above the portfolio. Everything below is governed by these. Three are familiar from LPM. Two are new because the constraint moved.
Strategic OutcomesWhat must become true. Declared at the officer level, traced through every Effort.
Investment & FundingHow capacity is funded. What gets resourced. Portfolio economics.
Governance & Risk AppetiteGuardrails, AI policy, responsible use standards, and how much risk to carry. Bigger now than before.
AI Capability InvestmentFleet provisioning, AI tooling standards, model selection. New. Didn't exist before.
Knowledge InvestmentFunding the Domain Knowledge Network. Encoding expertise. Was implicit, now load-bearing.
The trace. Every Effort below walks back to the outcome it serves, in under a minute. The Intent Architect tends this thread, and orphaned work gets named in the open.
Portfolio Direction
Two Councils, One Line of Authority
A directing intelligence, not a review board. It meets the work, not the calendar.
Roles
Intent Council Seat
Officers. Direction and risk.Flow Council Seat
Runs the portfolio daily.Intent Architect
Serves every team, sits on none.Demand Enters Sponsored
Work does not arrive unowned. An officer stands behind every request before the portfolio sees it.
Source
An area raises it
Demand originates in the areas, business and technology alike, each behind its own officer group.
Sponsor
Its officer approves and commits
The sponsoring officer approves the request and commits to releasing the Decision Owner. That commitment is what makes No Owner, No Now enforceable.
Front Door
One intake, then triage
Every sponsored request enters the same front door. The Flow Council triages it against the portfolio rather than against the area it came from.
Two Tiers, One Line of Authority
Strategic · Intent Council
Intent Council
The officers. They own the outcome portfolio, set direction, standards, and risk appetite, and make the calls only officers can make.
Delegated authority down · cadence check-in and escalations up
Tactical · Closest to the Work
Flow Council
Trusted leads below the officers, running the portfolio every day. They triage intake, allot capacity, form and reform teams, route knowledge, and clear blockers within hours. This is where work decisions get made.
Product, technology, and portfolio capacity management in one room. Allocation calls are made together rather than passed along.
No Owner, No Now
Nothing enters the Now horizon without a named Decision Owner whose old duties are handed off and backfilled, so they can be there every day. The sponsoring officer commits that release at intake and the Flow Council enforces it at triage. Work with no owner waits in Next.
One Roadmap, Three Horizons
A single list is the only prioritization instrument. No backlog sprawl, no shadow queues.
Now
Owned and funded, in daily cycles
Next
Sponsored, waiting for an owner or capacity
Later
Directional intent, no commitments yet
Direction Meets the Work
Portfolio decisions happen when the work needs them. A blocked team waits hours for a call, never weeks for a meeting.
Outcomes, Not Velocity
Progress is measured by outcomes delivered and evidence produced. Story points and utilization disappear.
Fungible Capacity
The Flow Council holds one pool of people and agent fleets for the whole portfolio. Capacity is planned and released, never allocated to a standing team.
Plan
Size the pool
Each week the Flow Council sizes the human and agent capacity available against the Now horizon, so commitments are made against what exists.
Commit
Send it to an Effort
Capacity goes to an Effort for as long as that Effort needs it. No team holds a standing claim on people or on fleet.
Release
Return it to the pool
The moment an outcome is accepted, the people and the fleet return to the pool and the Flow Council redeploys them to the next Effort.
Flows Down
- Prioritized outcomes
- Decision-ready briefs
- Acceptance standards
Flows Up
- Daily evidence and demos
- Escalations with options
- Portfolio learning
Intent flows down · evidence flows up · judgment at the boundary
Effort Teams
+ AI Fleets
Execution Units
Small effort teams direct fleets of AI agents. Judgment stays human. Production does not.
Roles
Decision Owner
Owns the outcome. Accepts daily.Fleet Lead
Directs the fleet. Reviews at altitude.AI Agent Fleet
Produces at machine speed.Learning Seat
The way in. Optional, funded.The Crew
Decision Owner
A business domain expert, fluent in context engineering. Owns the outcome, sets what good looks like, and accepts the work
Comes from the knowledge network, sits with the team for most of the week
Fleet Lead
Holds technical judgment. Decomposes the spec for the fleet, curates the technical context it works from, and reviews at the level of contracts and risk rather than line by line. Carries the architecture the agents have no memory of
AI Agent Fleet
Spec, build, and test agents running in parallel. Drafts, implements, proves, and traces at machine speed. Powerful implementers with no judgment about what should be built
Bounded authority. The Decision Owner accepts inside the guardrails and risk appetite the Intent Council sets, and escalates to the Flow Council outside them. Bounding it is what makes real acceptance authority safe to grant in a regulated business.
Runs One Day Ahead
Specify
Spec-driven development. The spec is written as a testable contract, so the acceptance criteria exist before any code does.
Decision Owner + spec agent + a domain expert from the network
NEXT
DAY
DAY
Build Day
Build with AI
The fleet implements against the contract while humans direct, challenge, and course-correct.
Continuous
Harness
Every criterion in the spec becomes an executable check that runs on each push, proving shape, behavior, failure paths, and policy.
By Close
Judge
The Decision Owner accepts against a green harness, never against a demo alone, or names exactly what is blocking.
Daily PlanningFeeds tomorrow's spec
The meeting that closes the loop. After the demo, the Decision Owner, Fleet Lead, and a Flow Council lead read the result together and set what tomorrow's spec must cover, naming the domain expert it needs.
Two Things Land Every Day
A working increment from today's spec, and a ready spec for tomorrow's build.
Where the Day's Work Lands
Shipping is a destination decision, never a question of whether anything shipped.
Preferred
All the way to users
Where regulatory clearance and the delivery pipeline allow it, the increment reaches production and real users the same day.
The Floor, Always
A hands-on environment
Otherwise it lands somewhere stakeholders can open it and use it themselves. Never a slide, never a status report.
Or
Learn
Not accepted means the blocking constraint is named that day and redirects tomorrow's spec.
One Effort, End to End
An Effort names the outcome to reach, never the solution to build. A team takes one Effort from spec to landed increment with no handoffs. Not a codebase, not a product, not a backlog lane. When the outcome is accepted the team dissolves back into the pool.
Flow Council decides when a team changes
Fluid Between, Stable Within
A team is two or three humans plus their fleet, and it holds together for the whole life of one Effort. Reformation happens at the boundary between Efforts.
The outcome is accepted and capacity releases
A higher-value Effort outranks it at triage
The Effort proves to need different expertise
Never mid-Effort for convenience. Context is the expensive thing to rebuild.
Built by the fleet · owned by the Decision Owner
The Harness Is the Owner's Instrument
It is how a business person accepts without reading code. Agents write and maintain the coverage. The Fleet Lead owns its integrity, because checks written against the implementation rather than against the spec prove nothing.
Flows In
- Outcome briefs
- Domain context
- Guardrails and standards
Flows Out
- Working increments
- Evidence packs
- Questions and edge cases
Knowledge is pushed into the work before teams stall · questions and patterns flow back
New Structural Layer
Domain Knowledge Network
Today's Bottleneck
A new layer of the organization. When execution stops being the constraint, domain context becomes the scarce resource.
Roles
Domain Expert
Floats on the guild, 20-30%.Owners From the Guild
The embedded exception.A governing structure, not a help desk. The network owns correctness. The Decision Owner owns the outcome. Its knowledge governs in three verbs. It is injected at spec time before the fleet starts, encoded into the harness where it enforces itself on every push, and returned as learning that changes what the next team receives.
The Guild
Regulatory
Compliance
Domain Experts
Policy
Data
Business Analysis
Customer Evidence
Everyone floats. No one is dedicated. Membership is named and funded, a committed slice of each expert's week rather than a favor their manager grants.
Decision Owners come from this guild and stay. They are the team's resident domain knowledge, so the team can decide day to day without waiting. The network is called for reach the owner does not have.
At Spec Time
Inject
Context, policy constraints, and validation criteria arrive while the spec is being written, before the fleet starts. Knowledge lands ahead of the work, never behind it.
Into the Harness
Encode
The expert's criteria become executable checks and their context joins the knowledge graph. Their judgment now runs on every push, for every team, without them in the room. This is how a small guild governs a whole portfolio.
After Each Cycle
Return
Edge cases, questions, and new patterns flow back, update the playbooks, and change what the next team receives. The network compounds instead of repeating itself.
Routed by Signal, Not Request
Daily planning names the expert tomorrow's spec needs. Each morning the network reads the day's specs and dispatches. The rota is set at weekly Flow Council calibration. Nobody is pulled reactively.
Encode, Don't Just Explain
Every contribution leaves something behind that outlives the conversation. A check in the harness, a playbook update, context in the graph. Explaining it to the people in the room is necessary and not sufficient.
Thirty Minutes, Into the Spec
A specialist works the spec directly with the Decision Owner and hands over the constraints and criteria their area requires. A working session, not a review meeting.
Into the Work
- Domain context
- Policy constraints
- Validation criteria
Back From the Work
- Questions and edge cases
- New patterns
- Updated playbooks
Intent Control Plane
Five connected capabilities. One source of truth for purpose, authority, action, and evidence.
Intent Graph
Purpose, work, ownership, and relationships in one lasting graph
The Intent Council sets direction · the Flow Council sequences capacity
Context & Knowledge
Admissible context and expertise wired to the intent that needs it
The network supplies it · every cycle returns learning
Governed Orchestration
Authorized human and agent capacity coordinated across tools
The Flow Council plans it · leads direct execution
Evidence & Judgment
Every result carries its proof chain and accountable decision
The harness contributes proof · the owner accepts
Authority & Policy
Permissions, constraints, and judgment gates travel with the work
The Intent Council sets bounds · policy travels with execution
Humans Direct
- Choose the outcomes that matter
- Engineer the context the fleet works from
- Define success and constraints
- Resolve ambiguity and trade off
- Accept value, stay accountable
AI Produces
- Drafts the spec with the owner
- Writes and runs the harness in CI
- Surfaces knowledge and dependencies
- Preserves evidence and traceability
Replaces
- Sprint planning. No sprints
- Program governance. The portfolio swarms crews to Efforts
- Role-based assignment. Skills flex
- Knowledge hoarding. Context flows
- Status reporting. The ledger is read
- A separate QA phase. The harness runs in CI
- Demo-only acceptance. Proof, not theater
Preserves
- Strategic alignment
- Quality judgment
- Daily accountability
- Regulatory safety
- Audit trail and traceability
- Test coverage as a contract
Foundations of the AI-Native Organization
2
The spec is a testable contract, written before the build.
3
Every outcome has one business owner, present every day.
4
One roadmap. Three horizons. No shadow queues.
5
Every day ends in someone's hands, or with a named blocker.
6
Knowledge is pushed to the work, not pulled.
7
Governance travels with the work.
8
Learning compounds across the portfolio.
Axioms and Operating Principles
I
Axiom I
AI amplifies direction; it does not choose it.
- Define outcomes before generating work.
- Make success testable before the build begins.
- Keep every active Effort traceable to declared intent.
Enforced by
II
Axiom II
As execution compresses, the constraint moves to knowledge and judgment.
- Organize the system around knowledge throughput.
- Push domain knowledge to the work before teams stall.
- Fund knowledge and judgment as explicit capacity.
Enforced by
III
Axiom III
Machines can produce; only humans can own.
- Name one Decision Owner for every active effort.
- Judge outputs against intent and evidence.
- Delegate authority only inside explicit boundaries.
Enforced by
IV
Axiom IV
Governance must move at the speed of the work.
- Encode policy and constraints into the spec and harness.
- Let ordinary work flow inside established guardrails.
- Escalate exceptions through a bounded, visible path.
Enforced by
V
Axiom V
Output is not value; changed outcomes are.
- Measure outcomes, not activity or velocity.
- Put each day's increment into someone's hands.
- If it cannot land, name the blocker and change tomorrow's spec.
Enforced by
VI
Axiom VI
Learning compounds only when evidence changes the next decision.
- Return questions and edge cases to the knowledge network.
- Update playbooks, guardrails, and roadmaps from what happened.
- Share learning across the portfolio, not inside one team.
Enforced by
Operating Guideline
Organize around knowledge throughput, not delivery capacity. As delivery time for a unit of work falls toward zero, the constraint moves to the slowest remaining human step: deciding what should be built, judging whether what came back is right, and supplying the domain knowledge needed for either call.
An organization built around the old constraint cannot feel the benefit. Planning increments, standing teams, stage-gate review, and sprint ceremony all exist to schedule and coordinate scarce delivery capacity. Point them at abundant delivery capacity and they hold it back rather than release it.
Operating Guideline
The spec is a testable contract, written before the build. One day's spec is one increment, roughly 5-15 acceptance criteria, and it fits on one page. If it does not fit on a page, it is two specs.
An hour spent on the spec saves roughly ten hours of rework downstream, and AI makes that ratio worse if you skip the spec, because the fleet produces far more implementation per hour for a reviewer to unwind. Speed of production raises the cost of ambiguity.
Operating Guideline
Every outcome has one business owner, present every day. If the Decision Owner cannot accept, they are not an owner, and the daily cycle does not close. This is the most important thing to hold when the model meets an existing approval culture.
Organizations adopting this model tend to leave Judge with a committee or with a manager outside the team. Doing that reintroduces the queue the model exists to remove and strands the Decision Owner with accountability but no authority.
Operating Guideline
One roadmap. Three horizons. No shadow queues. A single list is the only prioritization instrument. The boundary that matters is between Next and Now, and the No Owner No Now gate guards it.
Anything can be added to Later cheaply, which is exactly why commitments live only in Now. This keeps the roadmap honest and prevents the backlog sprawl that plagues traditional portfolio management.
Operating Guideline
Every day ends in someone's hands, or with a named blocker. The unacceptable end to a day is “it's not quite there yet.” The acceptable ends are: accepted and landed; not accepted because specific criteria fail and here is the evidence; or not accepted because a decision is required that the owner cannot make inside their envelope.
If a team ends days vaguely, the spec was vague. Go back to the checkability test.
Operating Guideline
Knowledge is pushed to the work, not pulled. The Domain Knowledge Network works on a push model. Each morning the network reads the day's specs and dispatches. Governance arrives as knowledge on the way in, rather than as a review queue on the way out.
A team that has to pull for domain knowledge is a team that stalls. The push model, driven by daily planning, prevents that stall.
Operating Guideline
Governance travels with the work. The model does not weaken control. It moves control from inspection after the fact to enforcement inside the work. Policy constraints are enforced by the harness, the audit trail is a byproduct, and escalation is bounded and fast.
Governance answers three questions continuously: Are we doing the right things? Are we building them right? Are we learning?
Operating Guideline
Learning compounds across the portfolio. Every cycle's questions and edge cases return through the Domain Knowledge Network and update the playbooks, the spec queue, and the roadmap. The network compounds instead of repeating itself.
The harness is an asset that compounds. Every Effort adds checks that outlive it, so the cost of proving the next increment falls over time while confidence rises.
Foundation
AI can accelerate work, expose options, and execute with precision. It cannot decide what should become true. Direction remains an organizational responsibility.
Operating Principles
- Define outcomes before generating work.
- Make success testable before the build begins.
- Keep every active Effort traceable to declared intent.
How the Model Enforces It
Foundation
When AI makes production faster and more abundant, the limiting work becomes knowing what matters, supplying the right context, and judging what comes back.
Operating Principles
- Organize the system around knowledge throughput.
- Push domain knowledge to the work before teams stall.
- Fund knowledge and judgment as explicit capacity.
How the Model Enforces It
Foundation
Production can move to agent fleets. Responsibility for purpose, boundaries, tradeoffs, and acceptance remains with a named person who has authority to decide.
Operating Principles
- Name one Decision Owner for every active effort.
- Judge outputs against intent and evidence.
- Delegate authority only inside explicit boundaries.
How the Model Enforces It
Foundation
Control that arrives after execution creates queues without preventing risk. Effective governance enters as knowledge, enforces itself continuously, and escalates true exceptions quickly.
Operating Principles
- Encode policy and constraints into the spec and harness.
- Let ordinary work flow inside established guardrails.
- Escalate exceptions through a bounded, visible path.
How the Model Enforces It
Foundation
AI can produce enormous volumes of convincing activity. Value exists only when the work changes something observable for a customer, operator, or organizational outcome.
Operating Principles
- Measure outcomes, not activity or velocity.
- Put each day's increment into someone's hands.
- If it cannot land, name the blocker and change tomorrow's spec.
How the Model Enforces It
Foundation
Experience does not become organizational learning by being documented. It compounds when evidence returns to the system and changes what the next team receives and decides.
Operating Principles
- Return questions and edge cases to the knowledge network.
- Update playbooks, guardrails, and roadmaps from what happened.
- Share learning across the portfolio, not inside one team.
How the Model Enforces It
Direction
The People
The Intent Council is the officer body. It owns the outcome portfolio, sets direction and standards, holds risk appetite, and decides what only officers can decide. It does not run the work.
Two Groups, One Line of Authority
The line between the Intent Council and the Flow Council is narrow. Authority is delegated down from the Intent Council once, and evidence and escalations travel back up on cadence. A blocker the Flow Council cannot resolve goes to the Intent Council at the next check-in, never later than one cadence.
Getting the boundary wrong is costly in both directions. If the Intent Council makes work decisions, everything queues behind an officer calendar and the daily cycle dies. If the Flow Council makes strategy decisions, the portfolio drifts from the organizational objectives and nobody notices until a quarterly review.
Held by the Officers
The Intent Council decides what only officers can decide. Specifically:
- Strategic direction: Setting the Now / Next / Later horizons and resetting them against landed evidence at the biweekly working session and the quarterly rebalance
- Risk appetite: Defining how much risk the portfolio can carry and where the boundaries are
- Regulatory interpretation: Deciding what a regulation means for the organization's work
- New external commitments: Anything that creates an obligation to a counterparty
- The bounded authority envelope: Setting the guardrails within which each Decision Owner may accept work unilaterally
- Standards and policy: What the organization requires of its work, encoded into guardrails and enforced by the harness
Delegated Down
Everything else delegates to the Flow Council. Specifically:
- Triaging intake against the portfolio
- Naming Decision Owners and enforcing the No Owner No Now gate
- Forming and reforming teams
- Planning, committing, and releasing capacity
- Routing domain knowledge to where it will be needed
- Clearing blockers within hours
- All daily work decisions
The boundary is enforced by cadence. The Flow Council runs the work daily and weekly. The Intent Council reviews evidence and resets direction biweekly. If the Intent Council is making decisions more often than biweekly, it is reaching into work decisions. If the Flow Council is waiting for the Intent Council to make daily calls, the delegation has not happened.
The Shift They Have to Make
The hardest part of this transition is behavioral, not structural. Intent Council members must delegate the daily work decisions to the Flow Council and trust the evidence that flows back up on cadence. The temptation to reach into work decisions because they are visible and important is the single most common way the daily cycle dies.
Still on the Old Path
Regulatory interpretation, risk appetite, and new external commitments remain Intent Council decisions on their existing cadence. The model does not compress these, and claiming otherwise is how transformations lose credibility with a second line of defense.
For a risk audience, lead with evidence rather than speed. This model produces more evidence, more often, at a finer grain, and with clearer attribution than the process it replaces.
Direction
The People
The Flow Council is the governing body closest to the work. It runs the portfolio day to day, triaging intake, allotting capacity, forming and reforming teams, routing knowledge, and clearing blockers within hours. Almost every decision a team feels comes from the Flow Council rather than the Intent Council.
Composition
The Flow Council is a deliberative group rather than a single discipline. Three perspectives have to be present when capacity is allocated, because an allocation made without any one of them fails in a predictable way.
Portfolio and product. What is most valuable, what sequence outcomes should run in, and what the organizational objectives require. Without this the pool gets spent on whatever is easiest to start.
Technology. What is feasible, where technical risk sits, what the fleet does well and does not do well yet, and what an Effort will touch architecturally. Without this the roadmap commits to work that cannot be built the way it was imagined.
Portfolio capacity management. Who and what is genuinely available, net of leave and standing obligations, and what is due to release back to the pool. Without this the group commits capacity it does not have.
These are perspectives rather than seats. In a smaller portfolio one person can carry two of them. The rule is that no allocation call is made with one of the three absent.
The call is made in the room, together. The pattern this replaces is sequential, where product sets priority, technology estimates afterwards, and capacity is found later still. That sequence reintroduces the handoffs the model exists to remove.
Five to nine people is the workable range. Below five it becomes a single point of failure. Above nine it becomes a committee and loses the ability to decide within hours.
The Shift They Have to Make
The hardest part of this transition is behavioral, not structural. Most Flow Council members will arrive from a role that rewarded them for one part of the portfolio. A Flow Council lead is rewarded for the whole portfolio's outcome, which regularly means giving capacity away from work they personally care about.
Work across the whole organization instead of driving one area's progress in a silo. Make this explicit in how Flow Council members are evaluated, or the old incentive reasserts itself and you will have rebuilt silos with new names.
Their Work
Triage every intake against the Now / Next / Later horizons. Name Decision Owners and enforce the No Owner No Now gate. Form and reform teams. Plan, commit, and release capacity. Route domain knowledge to where it will be needed. Clear blockers within hours. Carry to the officers only what requires officer authority.
Holding the horizons to precise meanings is what keeps the roadmap honest. Now is owned and funded, in daily cycles. Next is sponsored and waiting for an owner or capacity. Later is directional intent with no commitments attached. The boundary to guard is the one between Next and Now, and the No Owner No Now gate is what guards it. Anything can be added to Later cheaply, which is exactly why commitments live only in Now.
Cadence
- Daily. A Flow Council lead attends each team's daily planning. Blockers raised are resolved or escalated the same evening.
- Weekly. Full Flow Council calibration. Capacity is re-planned, domain experts are rotated, and the Now horizon is re-sequenced if the week's learning warrants it.
- Biweekly. The Flow Council checks in to the Intent Council at the strategic working session. Evidence is reviewed and direction is reset.
Formation and the Gate
Team formation follows the fluid-between-stable-within rule, and nothing enters Now without a named Decision Owner released to the committed level. Both mechanisms have their own cards on this placemat: Fluid Between, Stable Within and No Owner, No Now.
The Landing Spot
The council's operating muscle has a natural shortlist. The people who ran programs, ceremonies, and PMOs carry exactly the coordination craft that triage, calibration, and the capacity ledger need, pointed at a faster clock.
Direction
The Gate
Nothing enters the Now horizon without a named Decision Owner whose old duties are handed off and backfilled, so they can be there every day. The sponsoring officer commits that release at intake and the Flow Council enforces it at triage. Work with no owner waits in Next.
The Teeth of the Gate
This is the gate that converts business ownership from an aspiration into a funded constraint. It puts the true cost of an initiative on the table at intake rather than three months in. Expect it to be tested repeatedly in the first quarter. Holding it is the difference between this model working and this model becoming vocabulary.
Enforcement
A Decision Owner is released for at least 60% of their working week to a single outcome. Below that they cannot be present daily, and daily presence is the entire mechanism. They own one active outcome at a time. Not two. The moment someone owns two, both cycles degrade to the speed of their calendar.
Failure Modes and Their Tells
| Failure | Tell | Correction |
|---|---|---|
| Decision Owner is a proxy | Acceptance decisions consistently take more than a day, or the owner says “let me check with” | Replace the owner. Do not coach around this one. |
| Owner released on paper only | The owner misses daily planning more than once a week | Flow Council raises release level or moves the outcome back to Next. |
| Capacity never released | Same people on the same Effort beyond the outcome | Make release a minuted Flow Council action with a date. |
| Standing teams reassemble | Flow Council members advocate for “their” teams | Change how Flow Council members are evaluated. |
Failure tells for the spec, the harness, and the network live in their own cards. This table holds the ones the gate itself must catch.
Domain Judgment
The Qualification Test
A business domain expert, fluent in context engineering, who owns an outcome and accepts the work.
The qualification test is short. If they have to leave the room to answer a question about what the business needs or what the customer values, they are a proxy and not an owner. A proxy will silently stretch the one-day cycle back into a week, because every acceptance decision becomes a round trip to somebody else.
Three practical screens before naming someone:
- Can they describe, without preparation, what the outcome is worth and who is harmed if it is wrong?
- Can they say no to a stakeholder request without escalating?
- Have they ever been accountable for a business result rather than for a deliverable?
- Have they watched a customer use, buy, or struggle with the thing this outcome touches, within the last quarter?
Three of four is enough to start. Zero of four means you have found a coordinator, not an owner.
Time Commitment
This constraint kills the model when it is fudged, so it is stated as a hard number.
A Decision Owner is released for at least 60% of their working week to a single outcome. Below that they cannot be present daily, and daily presence is the entire mechanism. The remaining 40% stays in the business, and that is a design decision rather than a leftover. This is one job with two seats, not two jobs run in parallel. The old duties are handed off and backfilled, and neither seat carries deliverables from the former desk. In the business seat the owner scouts, free to be at the airport gate during the meltdown, in the claims office after the storm, or on the ride-along with the store greeter, listening for what could become the next thing worth building. In the tech seat they face delivery and turn what the field surfaced into specs a fleet can run and acceptance made daily. Business and customer knowledge are perishable, and they are refreshed only by doing the business. An owner embedded full time stops being a business person within a year and starts carrying last year's customer. The 40% is what keeps the owner an owner.
They own one active outcome at a time. Not two. The moment someone owns two, both cycles degrade to the speed of their calendar.
Where the 60% goes on a typical day:
| Activity | Time |
|---|---|
| Spec work on tomorrow's increment | 45 to 90 minutes |
| Available to the team for in-flight questions | 2 to 3 hours, responsive rather than scheduled |
| Demo, judgment, and acceptance | 30 to 45 minutes |
| Daily planning | 20 minutes |
The “available” block is the one leaders try to cut, and it is the one to protect first. A Fleet Lead blocked for four hours waiting on a judgment call has burned a build day.
When the Owner Is Away
Daily presence is the mechanism, so absence has to be planned rather than absorbed. Three cases, and they behave differently.
A day or two. Name a deputy at formation, usually the Fleet Lead or a second business person from the same guild. The deputy accepts only increments where the harness is green and no policy constraint is touched. Anything else waits for the owner. Narrowing the deputy's envelope this way keeps a short absence from becoming a decision the owner would not have made.
A week or more, planned. The Effort either transfers to a new Decision Owner with a proper handover of spec history and context, or it returns to Next until the owner is back. Running a multi-day absence on a deputy produces a proxy owner by another route.
Unplanned and open-ended. Treat it as a release lapse. The Effort returns to Next, capacity goes back to the pool, and the sponsoring officer is asked for a replacement owner. This is unwelcome and it is still cheaper than a cycle that stops closing while everyone waits.
Deputies are named at formation rather than found on the morning someone calls in sick.
Context Engineering Fluency
This is the new skill, and it is learnable in weeks rather than years. Concretely it means four things.
Knowing what the fleet needs to be told. Agents rarely fail because the work was hard. They fail because something was not stated. Fluency is the habit of noticing what you know that the fleet does not, and writing it down before it becomes a defect.
Writing criteria that are checkable. For every line, ask whether you can write a check for it. “Handles errors gracefully” fails. “Returns HTTP 400 with a structured error body naming the invalid field” passes.
Curating the context set. Which policy documents, prior decisions, data dictionaries, and edge cases belong in the fleet's working context for this increment, and which are noise. More context is not better context.
Reading agent output critically. Recognizing when the fleet has produced something plausible and wrong. This is judgment applied to machine output, and it is the skill that separates an owner who can accept in thirty minutes from one who needs a day.
Build it by pairing a new Decision Owner with an experienced Fleet Lead for their first two weeks of spec sessions. It transfers by apprenticeship, not by training course.
Authority, Finally Grantable
Every agile framework of the last twenty years has asked for an empowered product owner, and outside startups and founders it has rarely happened. Treat that as information rather than as a failure of conviction. Acceptance was largely invisible, the blast radius of a wrong call was unbounded, and the available control was to route decisions through a committee.
Four things change what granting that authority costs.
- The envelope is set once, by the Intent Council. What the owner may accept unilaterally, what escalates, and the risk appetite are written at the start of the outcome, not renegotiated per decision.
- Every acceptance is made against evidence. The harness proves each increment, and the acceptance is recorded with its evidence in the ledger. Authority is exercised in daylight.
- The blast radius is bounded. One increment, one day, rollback proven, policy checks enforced in CI. A wrong acceptance is a cheap, visible, same-day correction rather than a quarter of drift.
- The sponsorship is an officer's. The sponsoring officer staked the outcome and released this person. The authority arrives with backing, not by exception.
Underneath the four sits a simpler law. Authority flows to wherever the apparatus for exercising it exists. Executive decisions travel wrapped in staff work, controls, and audit, and the working level never had that apparatus, so authority pooled at the top. The envelope, the harness, and the ledger are the apparatus finally arriving where the work happens.
One implication follows directly. If acceptance authority is withheld from the Decision Owner, the daily cycle cannot close, and the rest of the model runs at the speed of whatever approves in its place.
Bounded Authority
The Decision Owner accepts inside an envelope the Intent Council sets once, in writing, at the start of an outcome. The envelope names the guardrails, the risk appetite, and the categories that must escalate.
The default envelope, what the owner accepts unilaterally, what escalates to the Flow Council, and what stays with the Intent Council, is detailed in the Bounded Authority card on this placemat. It is what makes daily acceptance safe in a regulated business.
Execution
A Distinct Role
One to three in a crew, the small human complement wrapped around a fleet, the human component of the fleet itself. They are fleet drivers, knowledge-holding dispatchers of agentic coders. They specify the technical approach, drive the agent fleet, and hold technical judgment. Their scarce contribution is not code. It is knowing when the fleet has produced something that looks right and is not.
Four Things That Make Fleet Lead Distinct
They are the technical context engineer. The mirror of what the Decision Owner does for business context. They curate what the fleet knows about the codebase, its conventions, its prior decisions, and its constraints. A fleet working from thin technical context produces plausible code that fits nothing around it.
They review at altitude. When the fleet produces several times more implementation per day than a person can read, line-by-line review stops being possible and pretending otherwise is how defects get waved through. The Fleet Lead reviews contracts, interfaces, data handling, failure paths, and anything touching policy. They read lines only where risk concentrates.
They carry the architecture. Agents have no memory of why the system is shaped as it is. Across days and across Efforts, the Fleet Lead is that memory. This is the part that cannot be delegated to the fleet at any capability level, because it is knowledge about intent rather than about code.
They are the reading requirement. Fluent upward in intent, fluent downward in code. Production no longer needs human hands, and accountability still needs human reading. An organization whose systems no human can audit has become a passenger in them.
They decide when to intervene rather than redirect. Recognizing that a fleet is looping rather than progressing, and stepping in directly, is a judgment call made several times a day. Getting it wrong in one direction wastes hours of machine work, and in the other it removes the leverage the model exists for.
How Many Agents Can One Lead Direct
Treat this as a real capacity question rather than an unlimited one. A fleet is not even a fixed size. Agents spawn agents when work splits, so the formation swells and thins under the lead's eye. In practice the constraint is not agent availability but how much output one person can meaningfully review at altitude. Start conservative, measure where review quality degrades, and let the observed number inform how the Flow Council sizes fleet capacity.
Concretely they own the decomposition of the spec into fleet-executable work, the integrity of the harness, the technical constraints the spec does not state, and the decision about when to stop directing agents and intervene directly.
Three Things Are Owned Differently
The Decision Owner owns the outcome. They are accountable for whether the business result is achieved, and they are the one who accepts.
The team owns the Effort. One team takes an Effort from spec to landed increment with no handoffs to another group. They do not own a codebase, a product, or a backlog lane, and they dissolve back into the pool when the outcome is accepted.
The Domain Knowledge Network owns correctness. Whether the work is right against policy and regulation is the network's accountability rather than the team's or the owner's.
Nobody owns a system. That absence is what makes capacity fungible.
Execution
The Shape of It
An optional seat on any crew for a code-fluent junior, reading at altitude beside a senior Fleet Lead. Not a shadow and not spare hands. A named, funded position whose output is the next generation of judgment.
Structural, Not Hopeful
The tasks juniors used to learn on were absorbed by the fleets first. Left to hope, the entry path closes, and ten years later nobody holds the theory of any system. The seat converts the pipeline from a hope into a mechanic.
How It Works
The junior sits inside the crew's daily rhythm, the spec sessions, the altitude reviews, the intervention calls, absorbing the theory of the system the only way theory transfers, by working under someone who holds it. They drive supervised lanes of the fleet as their judgment earns it.
The Test
A crew that has run a year with a learning seat should be able to name what its junior can now accept, review, and drive alone. If nothing has moved, the seat was a chair, not an apprenticeship.
Execution
Three Agent Roles
Three agent roles are worth distinguishing operationally. Each serves a different function in the daily cycle, and keeping them separate is a design decision with real consequences.
Spec agents draft the contract with the Decision Owner. They restate context, propose acceptance criteria from the outcome brief and the previous increments, and flag what they do not know. The Decision Owner corrects and signs rather than writing from scratch. Expect a usable draft in minutes. The governing ratio: if the Decision Owner is typing more than they are deciding, the balance is wrong.
Build agents implement against the contract. They work from the signed spec and the technical context the Fleet Lead provides. The Fleet Lead decomposes the spec into work the agents can execute, directs the fleet during the build day, and course-corrects as the work progresses.
Test agents write and maintain the harness coverage. They produce the automated checks that correspond to the acceptance criteria in the spec. Every "when X, then Y" in the spec becomes a check. The harness grows alongside the build, since test agents write and maintain coverage as build agents implement.
The Convergence Problem
A single agent that both implements and tests its own work will converge on tests that pass, which is not the same as tests that prove the spec. This is the single most important structural decision in how the fleet operates. An agent that writes tests against its own implementation rather than against the spec produces a green harness that proves nothing.
Keeping build and test agents separate is what makes the harness trustworthy. The Fleet Lead owns the harness's integrity and reviews that the checks correspond to the criteria rather than to the implementation. This is the single most important review the Fleet Lead performs, and it is why the Fleet Lead role cannot be eliminated.
Capacity
Agent fleet capacity is provisioned to Efforts by the Flow Council in the same pool as human capacity, because in practice it is a real constraint with real cost. Treat it as capacity, not as an unlimited utility. The Flow Council plans fleet capacity at weekly calibration alongside human capacity, because an Effort without sufficient fleet capacity is as stuck as one without a Fleet Lead.
Domain Judgment
The Shape of It
Spec-driven development. The spec is written as a testable contract a day ahead, so acceptance criteria exist before any code does. It is not a phase that precedes delivery. It is the first move of every single day.
The Volume Answer
One day's spec is one increment, roughly five to fifteen acceptance criteria, and it fits on one page.
If it does not fit on a page, it is two specs. If it has more than about fifteen criteria, the fleet cannot complete and prove it in a single build day, and you will end the day with a partial increment and no clean acceptance decision.
The Time Answer
45 to 90 minutes of the Decision Owner's day.
If they are spending three hours, one of three things is wrong. The slice is too big. The spec agent is not being used properly and they are typing prose a machine should draft. Or the outcome itself is under-specified at the level above, meaning the Flow Council handed down a brief that was not decision-ready.
The Authorship Split
The spec agent drafts. It produces the structure, restates the context, proposes acceptance criteria from the outcome brief and the previous increments, and flags what it does not know. Expect a usable draft in minutes.
The Decision Owner corrects and signs. They fix what the agent got wrong, delete what is noise, add the constraints only a domain person would know, and personally approve every acceptance criterion. The criteria are the one part they must author in substance, because the criteria are the judgment. Everything else can be machine-drafted.
The domain expert validates. A member of the Domain Knowledge Network reviews the criteria that touch their specialty. This is a 15 minute review, not a co-authoring session. They are checking correctness, not style.
The governing ratio: if the Decision Owner is typing more than they are deciding, the balance is wrong.
Inside a One-Day Spec
- The outcome this increment serves, in one sentence, traced to the Now horizon.
- Everything that already exists, so the fleet does not rebuild it.
- The behavior being added or changed, stated as “when X, then Y” so each clause becomes a check.
- Acceptance criteria, each independently checkable, each signed by the owner.
- Constraints and policy the increment must not violate.
- Explicitly out of scope, which is the cheapest defect prevention available.
- The open questions the owner expects to answer during the day.
The Spec Pays for Itself
An hour spent on the spec saves roughly ten hours of rework downstream, and AI makes that ratio worse if you skip the spec, because the fleet produces far more implementation per hour for a reviewer to unwind. Speed of production raises the cost of ambiguity. The spec is how you pay that cost down before it compounds.
Empowerment
| Step | Decision Rights |
|---|---|
| Specify | Decision Owner, with a spec agent and a domain expert |
Execution
Hour by Hour
Before the day starts. The spec exists, reviewed and signed. The domain context the increment needs has been injected by the Domain Knowledge Network. Nothing about the day's direction is open.
First hour. The Fleet Lead reads the spec with the fleet, decomposes it into work the agents can execute, and confirms the harness criteria are expressible as checks. If a criterion cannot be checked, that is raised now and not at 4pm. The Decision Owner is reachable for this hour specifically.
Middle of the day. The fleet implements against the contract. The harness grows alongside, since agents write and maintain coverage as they build. The Fleet Lead directs, reviews, and course-corrects. The Decision Owner answers questions as they arrive, typically three to six over the day, each taking minutes rather than a meeting.
Late afternoon. The harness runs clean, or it does not. The team prepares the demo against the criteria in the spec, not against a happy-path walkthrough.
End of day. Demo, judgment, acceptance or a named blocker, landing, then daily planning. Budget 45 to 60 minutes for all of it combined.
A Red Harness Is Not an Acceptance Decision
The most common way this cycle degrades is a team accepting an increment on a red harness because the failures look cosmetic. If the harness is red at close, the increment does not land. The day ends with the failing criteria named, and that is the blocker branch working as designed.
If a criterion is failing because the criterion is wrong rather than the build, that is a spec correction and it is made in daily planning, not waved through at acceptance. The distinction does real work because the second habit is how a harness stops meaning anything within a month.
The Working Week
The cycle runs on working days. A four-day week from a holiday is four cycles, not a compressed five, and the spec queue absorbs the gap without anyone re-planning. Teams that try to make up a lost cycle by doubling a spec produce the oversized increments described above.
Empowerment
| Step | Decision Rights |
|---|---|
| Build | Fleet Lead |
Execution
The Shape of It
The automated system that continuously validates what was built against what was specified. It runs on every push in CI. A harness that runs sometimes is a suggestion. A harness that runs on every push is a gate, and the gate is what creates the discipline.
The harness is not a developer tool the business happens to benefit from. It is the Decision Owner's instrument. It lets a business domain expert accept work every day without reading code, which is the mechanism the whole model rests on. Present it that way to a business audience, because presented as testing infrastructure it will be treated as an engineering concern and deprioritized.
It is also an asset that compounds. Every Effort adds checks that outlive it, so the cost of proving the next increment falls over time while the confidence rises.
The Four Layers
Shape. Interfaces return the right structures, status codes, and content types. Screens show the right fields. The data model matches the spec.
Behavior. Every “when X, then Y” in the spec becomes a check. This is the layer that carries the most acceptance weight.
Failure. Invalid input, missing data, unauthorized access, boundary conditions. The spec says what should happen, and the harness verifies it does.
Control. Policy constraints are enforced, and the audit trail is written. In a regulated environment this layer is not optional, and it is the layer that lets you accept daily without accumulating regulatory debt.
The Authorship
The agent fleet writes and maintains the coverage as it builds. The Fleet Lead owns the harness's integrity and reviews that the checks correspond to the criteria rather than to the implementation. An agent that writes tests against its own implementation rather than against the spec produces a green harness that proves nothing. This is the single most important review the Fleet Lead performs, and it is why the Fleet Lead role cannot be eliminated.
The End of QA as a Phase
Not because testing stopped mattering. Because testing moved from a downstream phase performed by a separate group to a continuous property of the build, authored by the fleet and gated in CI. What disappears is the handoff, the queue, and the lag.
The phase retires and the profession is promoted. People who spent careers thinking about how systems fail are the shortlist for harness stewardship, authoring the criteria test agents build from, confirming checks trace to the spec rather than the implementation, and growing coverage week over week.
What remains, and must be staffed, is exploratory testing for the things a harness cannot anticipate, and independent validation for high-risk changes. Expect this to be a small specialist function attached to the Flow Council rather than a team-level role.
The Relationship to Demos
Demos happen daily and are valuable. They show stakeholders the work in a form they can react to. A demo cannot carry the acceptance decision, because a demo shows one path through the system while the harness checks every path, every time. Acceptance is made against the harness and the evidence. The demo is how humans build intuition about what was built.
Domain Judgment
Judgment Inside the Loop
If Judge appears as a late step it reads as an approval gate, which is the mental model this operating model replaces. Judgment is not applied to the work after it is finished. It happens every day, on every increment, by the person who has been present the whole time.
The same correction applies to Specify. It is not a phase that precedes delivery. It is the first move of every single day. Specify and Judge are two faces of the same activity: the Decision Owner defines what right means in the morning and confirms it was achieved in the evening.
How It Works
The Decision Owner accepts against a green harness, never against a demo alone. The acceptance decision is made against evidence:
- The harness is green: every acceptance criterion in the spec has a passing check
- The demo confirms the behavior matches intent (the harness catches the letter; the demo catches the spirit)
- No policy constraint is violated
- The increment is recorded in the evidence ledger with its spec, criteria, harness results, and who accepted
A Red Harness Is Not an Acceptance Decision
The most common way this cycle degrades is a team accepting an increment on a red harness because the failures look cosmetic. If the harness is red at close, the increment does not land. The day ends with the failing criteria named, and that is the blocker branch working as designed.
If a criterion is failing because the criterion is wrong rather than the build, that is a spec correction and it is made in daily planning, not waved through at acceptance. The distinction does real work because the second habit is how a harness stops meaning anything within a month.
When a Day Fails
A failed day is one where the increment is not accepted. This is normal and should happen regularly. The requirement is that the failure is precise.
The unacceptable end to a day is "it's not quite there yet." The acceptable ends are:
- Accepted and landed
- Not accepted because specific criteria fail and here is the evidence
- Not accepted because a decision is required that the owner cannot make inside their envelope, and here is the exact question for the Flow Council
If a team ends days vaguely, the spec was vague. Go back to the checkability test.
Where This Is Most Often Weakened
Organizations adopting this model tend to leave Judge with a committee or with a manager outside the team, usually for comfort rather than for any stated reason. Doing that reintroduces the queue the model exists to remove, and it strands the Decision Owner with accountability but no authority.
If the Decision Owner cannot accept, they are not an owner, and the daily cycle does not close. This is the most important thing to hold when the model meets an existing approval culture. If acceptance authority is withheld from the Decision Owner, the daily cycle cannot close, and the rest of the model runs at the speed of whatever approves in its place.
Empowerment
| Step | Decision Rights |
|---|---|
| Judge | Decision Owner |
Direction
The Forum
Timebox. 20 minutes. It is a decision forum, not a status meeting.
Attendees. Decision Owner, Fleet Lead, and a Flow Council lead. The domain expert attends when the next increment touches their specialty, which is perhaps two days in five.
Position in the day. Immediately after the demo and the acceptance decision, while the evidence is fresh.
Agenda
- Today's landing, and where it landed. One minute.
- What the demo and the harness told us that we did not know this morning. Five minutes, and this is the substance of the meeting.
- Confirm, Amend, or Replace. Five minutes.
- Which domain expert tomorrow's spec needs, and whether they are available. Two minutes.
- Anything blocked that the Flow Council must clear tonight. Five minutes.
Outputs, Every Day Without Exception
A named decision on tomorrow's spec. A named domain expert if one is needed. A named blocker with an owner and a deadline, or an explicit statement that there are none.
The Tell That It Has Gone Wrong
If daily planning routinely runs past 30 minutes, it has become a working session. Split it. Decisions happen in the 20 minutes, and spec authoring happens afterward with only the people who write it.
Resolving the Day-Ahead Tension
State the tension plainly. Spec runs a day ahead so the build day starts ready. But the Decision Owner often does not know what they want next until they have seen today's demo. Those two facts appear to contradict each other. They do not, for four reasons that compound.
Most of Tomorrow's Spec Is Already Known
Separate every spec into two parts.
The stable part is the outcome, the constraints, the policy envelope, the data model, the acceptance philosophy, and the general shape of the next several increments. This is written days or weeks ahead and changes rarely. It is typically 70 to 80% of the spec's substance.
The volatile part is which specific slice comes next and its exact criteria. This is what the demo informs. It is the remaining 20 to 30%.
Once you see it this way, daily planning is not writing a spec from scratch in twenty minutes. It is making a small delta decision against a mostly-written contract.
The Buffer Is a Queue, Not a Fixed Lead Time
Do not think of it as “the spec is written exactly one day early.” Think of it as a shallow queue of one to three candidate specs, kept ready.
Most days the demo confirms the direction and you pull the next queued spec unchanged. Some days the demo surprises you and you reorder the queue or amend the spec at the top. The queue absorbs volatility that a rigid one-day lead time cannot.
Keep it shallow. A queue deeper than three specs is a backlog forming, and it means you are speculating further ahead than your learning rate justifies.
Three Calls at Daily Planning
At daily planning, after the demo, the group makes exactly one decision about tomorrow.
Confirm. The demo went as expected. Pull the next queued spec as written. This should be the majority of days, roughly 60 to 70% in a healthy team.
Amend. The demo revealed something that changes the next increment's criteria but not its direction. The Decision Owner adjusts the top spec that evening or first thing next morning, typically 20 to 30 minutes of work. Expect this 20 to 30% of days.
Replace. The demo invalidated the plan. The queued spec is wrong and a new one is needed. Expect this 5 to 15% of days.
When You Do Not Know, Spend a Cycle Finding Out
Replace days are not failures. They mean you learned something expensive early, which is the entire point of shipping daily.
When a Replace happens and the new direction is not yet clear, do not force a build day. Run tomorrow as a spec-and-explore cycle. The fleet investigates, prototypes throwaway options, and gathers what the owner needs to decide. The day still ends with something in someone's hands, but the artifact is a decision rather than an increment.
The Design Rule
If every demo overturns the plan, your slices are too big. A demo that invalidates a week of planned work means you planned a week ahead of your knowledge. A demo that adjusts tomorrow means you sliced correctly.
The Replace rate is a diagnostic. Persistently above 30% means slice smaller or admit the Effort is exploratory and change the cadence. Persistently at 0% means you are building something so well understood that you should question whether it needed this model at all.
Domain Judgment
The Preferred Destination
Where regulatory clearance and the delivery pipeline both allow it, the increment reaches production and real users the same day.
The Clearance Test
Run once per outcome and not per increment, it asks three questions:
- Does the change class have an approved deployment path?
- Does the control layer of the harness cover the applicable policy constraints?
- Is rollback automatic and proven?
Where all three hold, ship.
Establishing this for a class of change is high-value Flow Council work, because it converts every future increment in that class from a queued release into a same-day one.
Domain Judgment
Always Available
Where same-day production is not available, the increment lands somewhere stakeholders can open it and use it themselves.
This environment must have realistic data, be reachable without a scheduled session, and be current within one build day. Never a slide. Never a status report. Never a recorded walkthrough as a substitute. The point is that a stakeholder can form an independent opinion by using the thing, which is the only reliable way to surface a misunderstanding before it becomes expensive.
Cross-cutting
Not Accepted? Learn.
The increment is not accepted, the blocking constraint is named that day, and it redirects tomorrow's spec. Nothing sits in an ambiguous state overnight.
When You Do Not Know
When a Replace happens and the new direction is not yet clear, do not force a build day. Run tomorrow as a spec-and-explore cycle. The fleet investigates, prototypes throwaway options, and gathers what the owner needs to decide. The day still ends with something in someone's hands, but the artifact is a decision rather than an increment. This is the “learn” branch of ship-or-learn, and it is a legitimate, planned outcome rather than a lost day.
Domain Judgment
The Push Model
The network works on a push model rather than a pull model. This is the single most important design decision in how domain knowledge operates. A pull model means teams stall and then ask for help. A push model means knowledge arrives before anyone has to ask.
How Injection Works, Step by Step
- Daily planning names the expert. At the end of each day, during the 20-minute daily planning session, the team identifies which domain expert tomorrow's spec will need. This is agenda item four: "Which domain expert tomorrow's spec needs, and whether they are available."
- The network reads the signal. Each morning, the network reads what the day's specs require and connects the right expert to the right team before anyone has to ask.
- The expert works the spec directly. A typical contribution is a 15 to 30 minute working session, not a review cycle. The specialist works the spec directly with the Decision Owner and hands over the policy constraints and validation criteria the work must satisfy.
- The criteria enter the spec. The expert's constraints become acceptance criteria that the fleet builds against from the first line of code.
Governance arrives as knowledge on the way in, rather than as a review queue on the way out.
Machine speed raises those stakes from efficiency to survival. A fleet propagates whatever enters it with perfect fidelity, including a wrong assumption, so the only place to catch an error cheaply is before the build, which is exactly where the network stands.
Before, Not During
Knowledge that arrives after the fleet has started becomes rework. Knowledge that arrives at spec time becomes a constraint the fleet builds against from the first line. The difference is the difference between governing and reviewing.
In a traditional model, domain experts review output after it is built. In this model, their knowledge enters the work before the build starts and enforces itself automatically after they leave the room. That shift is what makes the daily cycle possible in a regulated environment.
The customer stream enters the same way. Evidence of what customers value arrives when the outcome brief is authored, cited and dated, rather than surfacing later as opinion in a review.
The Decision Owner Is the First Line
Because the Decision Owner is drawn from the domain guild and stays with the team, the team already holds the domain knowledge it needs for day to day decisions. The network exists for reach beyond what the owner carries. An Effort owned by one specialty that runs into another, a pricing outcome hitting a privacy rule, needs a specialist the owner is not. If a team is calling the network for questions its own Decision Owner could answer, the wrong person was named as owner. That is a naming failure, not a network failure, and it is fixed at formation.
The Rota
The rota itself is set at weekly Flow Council calibration, so expert availability is planned alongside capacity rather than begged for in the moment. The domain expert attends daily planning when the next increment touches their specialty, which is perhaps two days in five. Network membership is a named, funded commitment of typically 20 to 30% of each expert's week.
Domain Judgment
From Conversation to Enforcement
The step that makes a floating guild viable is not injection but what happens immediately after it. The expert's criteria are encoded into the harness, and their context joins the knowledge graph. From that moment their judgment runs on every push, for every team, without the expert in the room.
Encoding stores enforcement, and it does not replace the expert. A check enforces what was foreseen. The guild notices what was not, and noticing is the part that stays human.
This is the step that converts domain knowledge from a perishable conversation into a lasting asset. Without it, every expert contribution evaporates when the people in the room rotate, and the same question returns next month.
The Two Artifacts
Two things leave every expert interaction:
- Executable checks in the harness. The expert's policy constraints and validation criteria become automated checks that run in CI on every push. These are not documentation. They are enforcement. A credit constraint encoded into the harness is enforced thousands of times without the credit expert present.
- Context in the knowledge graph. The reasoning behind the constraint, the edge cases discussed, the interpretive decisions made. This context is wired to the work that needs it, so the next team working in the same domain inherits what was learned rather than re-discovering it. Customer evidence joins the graph with its date attached, so the next brief can tell current knowledge from last year's customer.
How a Small Guild Governs a Portfolio
This is what makes the layer workable. A guild of part-time experts (typically committed at 20 to 30% of their week) cannot attend every team's every cycle, and does not need to. Each contribution leaves executable checks and reusable context behind, so demand for specialist time falls as the portfolio learns.
The health test of the network is that expert hours per outcome trend down while coverage of their constraints trends up. If the opposite is happening, the encode step is being skipped and the network is consulting rather than governing.
The Rule for Every Contribution
Encode, not merely explain. Explaining the answer to the people in the room is necessary and not sufficient, because people rotate and memory fades. If nothing outlives the conversation, the network is consulting rather than governing, and the same question comes back next month.
The practical test after every expert session: can you point to the harness check or the knowledge graph entry that resulted? If the answer is no, the session was helpful but it did not encode, and the next team will pay the same cost again.
The Guild's Multiplier
Without encoding, the only way to scale domain governance is to hire more experts or dedicate them to teams. Both break the model: more experts are not available in most organizations, and dedicating them rebuilds standing teams. Encoding is the mechanism that lets a small, floating guild govern a large portfolio, because each contribution multiplies rather than merely adds.
Domain Judgment
How the Network Learns
Questions, edge cases, and new patterns flow back from teams into the network, where they update the playbooks the next team will receive. This is what makes the layer compound rather than merely serve. Without the return channel, the network falls back to one-way injection, which is helpful but not self-improving.
The Return Flow
Every team encounter with domain knowledge produces learning that belongs to the network, not to the team:
- New edge cases that no prior spec anticipated. These become new harness checks and new playbook entries.
- Policy questions that required interpretation. The interpretation, once made, becomes a constraint the next team inherits rather than re-discovers.
- Patterns of misunderstanding between business intent and fleet output. These reveal where the shared context is thin and where the knowledge graph needs enrichment.
- Corrections to existing playbooks where the current guidance proved incomplete or wrong in practice.
- Customer signal the work surfaced. Support themes, usage patterns, and acceptance evidence that confirm or contradict what the brief assumed customers value.
The Monthly Network Session
Budget a monthly two-hour network session specifically for absorbing what came back and revising the shared context. This is a working session, not a status meeting. The agenda:
- Review every question and edge case that surfaced since the last session
- Decide which ones change the playbooks, the harness templates, or the knowledge graph
- Make those changes in the session, not as follow-up actions that never happen
- Identify any pattern that suggests a gap in how experts are being dispatched
Skipping this session turns the network into a rota of interruptions. The experts inject knowledge but never benefit from what other teams learned, so the same questions recur and the same edge cases surprise.
A Network, Not a Rota
A staffing rota sends people where they are needed. A knowledge network sends people where they are needed and gets smarter each time it does. The return flow is the difference. Without it, expert hours per outcome stay flat or rise. With it, expert hours per outcome trend down while coverage of their constraints trends up, because each contribution leaves behind checks and context that serve every future team.
Domain Judgment
The Shape of It
A governing structure, not a help desk. It owns correctness, and correctness has two faces. Right against the rules, and right about what customers value. The Decision Owner owns the outcome.
It is a new layer of the organization, and it exists because when execution stops being the constraint, domain context becomes the scarce resource, and scarce resources need structure.
Membership
Regulatory, compliance, domain experts, policy, data, the business analysts who hold institutional knowledge, and the customer-facing people who carry the evidence of what customers value. Members remain in their home functions. Network membership is an additional, named, funded commitment of typically 20 to 30% of their week. The seats on the guild are knowledge streams, not job titles, and people map onto them in combinations. One person often carries two or three streams, a compliance lead who also holds policy, an analyst who holds domain and data. A stream may have several holders. The floor is that every stream has at least one named holder, and no stream depends on exactly one person for long, because the expert who leaves is this layer's highest-risk event.
The One Rule
Every expert floats and none are dedicated. They go where their knowledge is needed today.
The Decision Owner is the only exception, pulled from this same business guild and embedded with one team for most of the week, because someone has to be present to accept every single day. The rest of the owner's week stays in the business on purpose. The knowledge that made them worth naming is perishable, and it is refreshed only by doing the business.
The Decision Owner Is the First Line
Because the Decision Owner is drawn from this guild and stays with the team, the team already holds the domain knowledge it needs for day to day decisions. That is the point of embedding them. The team proceeds without waiting on anyone for knowledge its own owner carries.
The network exists for reach beyond what the owner carries. An Effort owned by a pricing expert that runs into a disclosure rule, or an operations outcome that hits a policy constraint, needs a specialist the owner is not. If a team is calling the network for questions its own Decision Owner could answer, the wrong person was named as owner. That is a naming failure rather than a network failure, and it is fixed at formation.
How the Network Learns
Questions, edge cases, and new patterns flow back from teams into the network, where they update the playbooks the next team will receive. This is what makes the layer compound rather than merely serve.
Budget a monthly two-hour network session for absorbing what came back and revising the shared context. Skipping this turns the network into a rota of interruptions.
Customer Truth
The customer seat is the one whose knowledge decays in months rather than years, so it runs on evidence rather than tenure. Every outcome brief cites customer evidence someone could be shown, and the evidence carries its date. A brief built on internal consensus is a guess the fleet will execute with perfect fidelity.
Health Test
Expert hours per outcome should trend down while coverage of their constraints trends up. If the opposite is happening, the network is consulting rather than governing, and the encode step is being skipped. A second test guards the customer stream. The evidence behind each active brief stays dated and recent. When those dates age, the network has started guessing.
Three Things Are Owned Differently
The Decision Owner owns the outcome. Accountable for whether the business result is achieved.
The team owns the Effort. One team takes it from spec to landed increment with no handoffs.
The Domain Knowledge Network owns correctness. Whether the work is right against policy and regulation, and honest about what customers value.
Nobody owns a system. That absence is what makes capacity fungible.
The Profile
Two things describe every seat, and neither is a job title. The disposition of a scout, business people who never stop tracking what customers care about, which is what is good for the business, which is what value is. And context engineering, the fluency to put what they know into the outcome brief, the Effort specs, and the acceptance criteria that describe the need, finished before the Fleet Lead decomposes it into the technical specs that drive the fleet.
Domain Judgment
In Their Keeping
The regulatory experts on the guild hold the interpretation of rules that govern what the organization can and cannot do. They translate regulations into constraints the work must satisfy.
How They Contribute
At spec time, the regulatory expert reviews criteria that touch regulated activity. Their constraints become acceptance criteria the fleet builds against. After the session, those constraints are encoded into the harness so they enforce themselves on every future push without the expert in the room.
Floating, by Design
A regulatory expert dedicated to one team covers that team. A regulatory expert on the network covers every team that touches regulated work. The encode step is what makes this scalable: each contribution leaves behind automated enforcement.
Domain Judgment
In Their Keeping
Compliance experts ensure the work meets the standards the organization has committed to, whether internal policy, industry standards, or external audit requirements.
How They Contribute
They review specs and acceptance criteria for compliance implications. Their knowledge enters the work at spec time and is encoded into the harness as automated checks. The audit trail the harness produces is a byproduct, not a separate deliverable.
The Shift
In the traditional model, compliance reviews output after the fact. In this model, compliance knowledge enters at spec time and enforces itself continuously. The compliance expert spends less time reviewing and more time teaching the system what to check.
Domain Judgment
In Their Keeping
The subject-matter experts who hold deep knowledge in the organization's core business domains. They know the edge cases, the history, and the reasons behind the rules that no document fully captures.
How They Contribute
Domain experts work the spec directly with the Decision Owner, typically a 15 to 30 minute session. They hand over the constraints and validation criteria the work must satisfy. Their knowledge is encoded into the harness and the knowledge graph so it compounds across teams and Efforts.
The Decision Owner Is the First Line
The Decision Owner is drawn from this same guild. The network is called for reach beyond what the owner carries. If a team is calling the network for questions its own owner could answer, the wrong person was named as owner.
Domain Judgment
In Their Keeping
Policy experts own the interpretation of internal standards and external requirements. They define the guardrails within which the work operates.
How They Contribute
Policy constraints are injected at spec time and encoded into the harness as automated checks. The Intent Council sets policy. The network encodes it. The harness enforces it. This chain replaces the review-after-the-fact pattern that created queues.
Policy Guardrails, Not Gates
The best governance teaches people how to move fast responsibly. Policy experts write constraints that enable speed within boundaries rather than gates that require approval for each use case.
Domain Judgment
In Their Keeping
Data experts hold knowledge about data models, data quality, data lineage, and the boundaries of what data can be shared with AI systems and what cannot.
How They Contribute
They review specs that touch data handling, integration, or reporting. Their constraints cover data sensitivity, accuracy requirements, and architectural implications. These are encoded into the harness as data validation checks.
The Data Trust Gap
What can be shared with AI, what cannot, and why. Data experts are the people who can answer this question for each use case, and their answers become guardrails encoded into the system.
Domain Judgment
In Their Keeping
Business analysts hold institutional knowledge: how processes actually work, where the exceptions live, what the documentation does not say. They are often the people who know why something is done the way it is done.
How They Contribute
They work the spec with the Decision Owner, contributing process knowledge and edge cases. Their institutional memory is encoded into the knowledge graph so it survives personnel changes.
The Shift
In the traditional model, BAs write requirements documents. In this model, their knowledge enters specs directly and is encoded into enforcement. The document is replaced by living checks and searchable context.
Domain Judgment
In Their Keeping
Direct evidence of what customers actually value. Research findings, service and support themes, sales conversations, usage patterns. The people who carry it face customers for a living, and theirs is the only knowledge on the guild that decays in months rather than years.
The Seat Every Guild Lacked
Every other seat on the guild keeps the work right against the rules. This one keeps it right about the customer. Without it, outcome briefs are written from internal consensus, and the fleet executes the organization's guess about the customer with perfect fidelity. In the old model a wrong guess had months of meetings to get caught in. In this one it compiles the same day.
How They Contribute
Customer evidence enters the outcome brief the way a policy constraint enters a spec. Every brief cites evidence someone could be shown, and the evidence carries its date. Stale evidence is visible on its face, and refreshing it is scheduled work rather than a hope.
The Rule
Evidence, not assumption. If nobody can point to where a customer said it, showed it, or did it, the brief records an assumption to be tested rather than a fact to build on. Internal consensus is to customer truth what consulting is to governing.
And the customers who matter most are outside the walls. Customer means whoever the organization exists to serve, and an internal chain of service has to trace out to them in the end. A chain that cannot find its way to anyone outside is not serving a customer. It is overhead defending itself.
Domain Judgment
The One Rule
Every expert floats and none are dedicated. They go where their knowledge is needed today. Membership is a named, funded commitment of typically 20 to 30% of each expert's week.
The Floating Arithmetic
A dedicated expert covers one team. A floating expert covers every team that touches their specialty. The encode step is what makes this sustainable: each contribution leaves behind automated checks that enforce themselves without the expert present.
The Exception
The Decision Owner is the only exception. They are pulled from this same guild and sit with one team for most of the week, because someone has to be present to accept every single day. The rest of their week stays in the business, which is what keeps their knowledge worth embedding. The network is called for reach the owner does not have.
How Floating Is Governed
The rota is set at weekly Flow Council calibration. Expert availability is planned alongside capacity rather than begged for in the moment. The domain expert attends daily planning when the next increment touches their specialty, which is perhaps two days in five.
Domain Judgment
Knowledge in the Room
The Decision Owner is drawn from the domain knowledge guild and stays with one team for most of the week, with the rest kept in the business so the knowledge they carry stays current. This means the team already holds the domain knowledge it needs for day-to-day decisions. The team proceeds without waiting on anyone for knowledge its own owner carries.
The First Line
Because the owner is embedded, most domain questions are answered immediately. The network exists for reach beyond what the owner carries. An outcome owned by one specialist that runs into a different specialty needs someone the owner is not.
The Naming Test
If a team is calling the network for questions its own Decision Owner could answer, the wrong person was named as owner. That is a naming failure, not a network failure, and it is fixed at formation.
The Four Screens
Four practical screens: Can they describe what the outcome is worth without preparation? Can they say no to a stakeholder without escalating? Have they ever been accountable for a business result rather than a deliverable? Have they watched a customer use, buy, or struggle with the thing this outcome touches within the last quarter? Three of four is enough to start. Zero of four means you have found a coordinator, not an owner.
Direction
The Pool
The Flow Council holds one pool of capacity for the portfolio, containing both people and agent fleets. Capacity is planned and released. It is never allocated to a standing team. The pool is the mechanism that makes fungibility real rather than aspirational.
Weekly Pool Sizing
Each week the Flow Council sizes the human and agent capacity available against the Now horizon. The sizing is done net of leave, standing business obligations, and the portion of Decision Owners' weeks not released. Commitments are made against what actually exists rather than against headcount.
The output is a simple statement, refreshed weekly:
- This many Decision Owners are available at the committed release level (at least 60%)
- This many Fleet Leads are available
- This much agent fleet capacity is provisioned
- Therefore this many Efforts can be in flight simultaneously
That last number is the binding constraint. If the portfolio has twelve outcomes in Now but capacity for eight Efforts, four outcomes must wait in Next. The No Owner No Now gate enforces this naturally, because you cannot name an owner you do not have.
Net of Leave and Obligations
The most common planning failure is counting people who are not actually available. A Decision Owner who is nominally released but carrying three standing committee obligations is not at 60%. A Fleet Lead returning from an Effort who has two weeks of deferred obligations is not available this week. Planning against gross headcount produces a number that looks comfortable and turns out to be fiction within days.
The weekly calibration is where the plan is rebuilt against reality. Capacity shifts week to week as people return from Efforts, go on leave, or are pulled into standing obligations. A plan older than a week is fiction.
Three Perspectives Must Be Present
Capacity planning requires three perspectives in the room together:
- Portfolio and product: What is most valuable and what sequence outcomes should run in
- Technology: What is feasible, where technical risk sits, and what the fleet does well
- Capacity management: Who and what is genuinely available, net of everything
An allocation made without any one of these three fails in a predictable way. The call is made in the room, together. The pattern this replaces is sequential, where product sets priority, technology estimates afterwards, and capacity is found later still.
Direction
To an Effort, Not a Duration
Capacity goes to an Effort for as long as that Effort needs it. No team holds a standing claim on people or on fleet. Commitment is to an Effort and not to a duration, which is what allows the model to absorb the reality that some outcomes take four days and some take four months.
Not Headcount
Traditional capacity planning counts heads and assigns them to teams or projects for a quarter or a year. This model counts available capacity, which is a different number. Available capacity is what exists after subtracting leave, standing business obligations, the portion of Decision Owners' weeks not released, and the time domain experts spend in their home functions. Headcount is a budget line. Available capacity is what you can actually commit.
The distinction does real work because an organization that plans against headcount will overcommit every quarter, discover the gap mid-flight, and either let Efforts starve or pull people off one Effort to feed another. Both destroy the daily cycle.
The Fungibility Principle
Because nobody owns a system or a codebase, any qualified person or fleet can be committed to any Effort. That fungibility is what lets the Flow Council move capacity to the highest-value work without a negotiation.
An organization that restores system ownership has lost the ability to move capacity, whatever the operating model says. System ownership creates implicit standing claims that prevent the Flow Council from redeploying people, even when the Effort they are on has ended.
The Council's Commitments
At weekly calibration, the Flow Council commits capacity to Efforts in the Now horizon. The commitment is explicit and recorded:
- A named Decision Owner at the committed release level (at least 60% of their week)
- A named Fleet Lead
- A stated amount of agent fleet capacity
- A named deputy for the Decision Owner's short absences
This commitment holds for the life of the Effort. It is not renegotiated sprint by sprint, because the Effort is the unit of commitment, not the iteration.
When Commitment Conflicts Arise
If a higher-value Effort enters Now and capacity is scarce, the Flow Council makes an explicit trade. They do not quietly starve one Effort to feed another. The Effort losing capacity either returns to Next with a recorded reason, or it continues with reduced scope and a revised acceptance envelope. The decision is made in the room, together, at calibration.
Direction
How an Effort Ends
Release depends on someone declaring the outcome met, and Efforts drift when nobody owns that call. Two people are involved in the closure decision, and both are necessary:
- The Decision Owner proposes closure when the outcome's acceptance criteria are satisfied. They are closest to the work and know when the outcome has been reached.
- The Flow Council confirms closure at weekly calibration. They hold the portfolio view and catch the case where an owner close to the work keeps going past the point of value.
Closure is a decision with a date, recorded like any other. It is not an event that happens when people drift away.
The Stall Signal
An Effort that has produced no landed increment for a week is raised at calibration whether or not the owner proposes closure. That pattern usually means one of three things:
- The outcome was reached and nobody declared it
- The Effort is blocked and the blocker was not escalated
- The Effort should never have entered Now and needs to return to Next
All three require a Flow Council decision, and the weekly calibration is where it happens.
The Half Most Organizations Skip
The moment an outcome is accepted, the people and the fleet return to the pool, and the Flow Council redeploys them to the next Effort, usually within the same week.
Release is the half most organizations skip, and skipping it is what rebuilds standing teams. If capacity never returns to the pool, within two quarters you have permanent teams with new labels and the model has failed silently.
Making Release Explicit
Make release an explicit, minuted Flow Council action with a date, not something that happens by drift. The release minute records:
- The Effort and outcome that concluded
- The date capacity returns to the pool
- Which people and fleet capacity are now available
- Where that capacity is redeployed (or that it enters the unallocated pool)
Without this discipline, capacity leaks. People stay attached to concluded Efforts out of habit, convenience, or because a manager wants them nearby for something that has not been formally triaged. Each leak is small. The cumulative effect is that the pool shrinks invisibly and the Flow Council cannot fund new Now items despite having the headcount.
The Failure Mode and Its Tell
| Failure | Tell | Correction |
|---|---|---|
| Capacity never released | Same people on the same Effort beyond the outcome | Make release a minuted Flow Council action with a date |
Direction
The Sponsored Door
Business areas raise requests through their own officer groups, and no request arrives without sponsorship. Technology is an area in full standing. A platform extension, a security upgrade, a migration off a dying system, a modernization the business will never ask for by name, all of it is raised by technology's own officers and sponsored the same way, never smuggled in as background work. Internal demand answers the same question at triage, the chain of service it ultimately serves, because an internal outcome earns capacity the way a customer-facing one does, by tracing to someone the organization exists to serve.
The Scouts Hear It First
A share of demand never starts as a request at all. It starts as something heard in the field by the network's own people. The Decision Owner in the scouting half of the week, the guild member in their home function, standing where the business touches people and carrying the standing question of what should be built next. The green layer feeds this strip before the work has a name.
The Starting Point
Demand that enters without a business area behind it has no home to return to when questions arise. The source determines who carries the context, who releases the Decision Owner, and who is accountable if the outcome does not land.
Direction
Dual Commitment
The sponsoring officer approves the request AND commits to releasing the Decision Owner. This dual commitment is what makes No Owner No Now enforceable. Without it, the Flow Council would be asking teams to find owners it has no authority to free.
Sponsorship, in Practice
The sponsoring officer is the only person who can release a business expert from their day job. Their approval is simultaneously the commitment of a Decision Owner. If they approve the work but do not release the person, the request waits in Next.
A Green Seat Changes Hands
The person being released is a guild member of the Domain Knowledge Network, already carrying the domain the request touches. The commitment is not a title moving between boxes. It is the network's deepest holder of that domain going forward to sit with the crew, which is why the sponsor's signature is the one green fact on the intake path.
Direction
One Intake, Then Triage
Every sponsored request enters the same front door. The Flow Council triages it against the portfolio rather than against the area it came from. This is the mechanism that prevents each business area from running its own shadow backlog.
Two Officer Groups, Distinct Roles
Keep the two officer groups distinct: sponsoring officers decide something is worth doing. The Intent Council decides where it sits against everything else. Confusing the two is how intake turns back into a queue of unfunded good ideas.
The Brief Arrives Carrying the Network
A request reaches triage as a brief, and a brief worth triaging already carries the knowledge layer's work. Known constraints that are encoded rather than remembered, and customer evidence with dates attached rather than assumptions. Triage reads what the network already knew.
Direction
The Single List
A single list is the only prioritization instrument. No backlog sprawl, no shadow queues.
Horizons
- Now: Owned and funded, in daily cycles. A named Decision Owner is released and capacity is committed.
- Next: Sponsored, waiting for an owner or capacity. Has officer backing but has not cleared the No Owner No Now gate.
- Later: Directional intent, no commitments yet. Anything can be added cheaply, which is exactly why commitments live only in Now.
The boundary to guard is the one between Next and Now. The No Owner No Now gate is what guards it.
Three Altitudes, Three Clocks
Now, Next, and Later recur at the team, portfolio, and enterprise levels with different units and clocks. This strip is the portfolio level, where movement between horizons happens at Effort boundaries, roughly monthly when Efforts are sized in weeks. The team shuffles its spec queue daily, and the enterprise shuffles strategic outcomes at the quarterly rebalance.
Direction
Portfolio decisions happen when the work needs them. A blocked team waits hours for a call, never weeks for a meeting. Any team can raise a blocker to the Flow Council on any day. The Flow Council resolves it or carries it to the Intent Council at the next check-in. No blocker outlives one cadence.
The Flow Council's daily cadence means a Flow Council lead attends each team's daily planning and can resolve blockers that same evening. This replaces the program board that meets monthly and the periodic portfolio review that convenes quarterly.
Direction
The Metrics
Measure the model's mechanics rather than delivery volume. Volume metrics will look strange during transition and will tempt people to game them.
Leading Indicators, Weekly
- Percentage of Now items with a named Decision Owner at the committed release level. Target 100%, because this is the gate.
- Decision Owner daily presence rate. Target above 90%.
- Confirm, Amend, and Replace ratio. Watch for drift rather than a target.
- Blocker resolution time against the one-cadence rule.
- Capacity released to the pool this week.
Outcome Indicators, Monthly
- Percentage of days ending in something a human could use, whether shipped to users or landed in a hands-on environment.
- Rework caught by the harness versus rework discovered at or after demo. The ratio should move sharply toward the harness.
- Time from intake to first landed increment.
- Percentage of increments shipping all the way to users, which measures pipeline and clearance maturity rather than team performance.
The Anti-Metrics
Velocity, story points, utilization, and agent output volume. Each of these actively distorts the behavior the model depends on.
Execution
An Effort names the outcome to reach, and never prescribes the solution. A team takes one Effort from spec to landed increment with no handoffs to another group. They do not own a codebase, a product, or a backlog lane, and they dissolve back into the pool when the outcome is accepted.
Three Things Are Owned Differently
- The Decision Owner owns the outcome. Accountable for whether the business result is achieved.
- The team owns the Effort. One team takes it from spec to landed increment with no handoffs.
- The Domain Knowledge Network owns correctness. Whether the work is right against policy and regulation, and honest about what customers value.
Nobody owns a system. That absence is what makes capacity fungible. An organization that restores system ownership has lost the ability to move capacity, whatever the operating model says.
Direction
When Teams Change
Fluid formation is a Flow Council decision rather than a team's, and it is narrower than the phrase suggests. A team is fluid between Efforts and stable within one.
A team holds together for the whole life of an Effort. The Flow Council reforms it at the boundary, on three triggers:
- The outcome is accepted and capacity releases back to the pool.
- A higher-value Effort outranks it at triage and capacity is redirected.
- The Effort proves to need different expertise than it appeared to need at formation.
Non-Triggers
Convenience, utilization smoothing, or a manager wanting someone back for something else. Rebuilding context is expensive. A team mid-Effort holds accumulated spec history, domain context, and harness knowledge that does not survive a handover.
The Decision Owner is the exception. If their release lapses, the Effort does not continue with a substitute. It returns to Next until sponsorship is restored, because the alternative is a proxy owner and a cycle that stops closing without anyone noticing.
Direction
The Anatomy of an Outcome
A statement of what must become true for the business, not a project and not a deliverable. “We will deploy AI” is an activity. “Decisions move to the point of work” is an outcome. An outcome is done when the condition holds, which may take less work than anyone imagined or more. The team stops when the condition is met, not when the backlog is empty.
Declared, Not Requested
Outcomes originate with officers. A request goes into a queue. A declaration carries the authority and resources to begin, because the officer who declares an outcome is committing to fund it: releasing a Decision Owner and allocating capacity. Sponsoring officers decide something is worth doing and fund the person to own it. The Intent Council decides where it sits against everything else in the portfolio.
The Enforcement
Every outcome is owned by one person, placed on one of the three horizons, and guarded by the No Owner No Now gate on the way into active work. Every daily spec opens with a one-sentence trace to the outcome it serves, which is how the organization knows, on any given day, whether the work across the portfolio connects to what the officers declared.
The Outcome Brief
Each outcome arrives with a short brief: the outcome statement in one sentence, why now, the sponsoring officer, the candidate Decision Owner, the known constraints, and what success looks like in terms the harness can eventually check. What the brief does not contain is a solution, a timeline, or a resource plan. Those emerge from the daily cycle. The Intent Architect holds the standard a brief must meet.
Direction
How capacity is funded and what gets resourced. The Flow Council holds one pool of people and agent fleets for the whole portfolio. Capacity is planned and released, never allocated to a standing team.
The AI-Era Shift
Funding now covers two types of capacity: human and fleet. Agent fleet capacity is provisioned to Efforts by the Flow Council in the same pool as human capacity, because in practice it is a real constraint with real cost. Treat it as capacity, not as an unlimited utility.
The sponsoring officer commits not just budget but the release of a Decision Owner. That commitment is what makes No Owner No Now enforceable and what puts the true cost of an initiative on the table at intake rather than three months in.
Direction
Guardrails, AI policy, responsible use standards, and risk appetite. This pillar got bigger when AI entered the organization, because the blast radius of ungoverned AI usage is larger and faster than anything that came before.
Risk Appetite, Declared Once
The appetite is the direction half of this input. How much risk the enterprise will carry, by category. Regulatory exposure, financial thresholds, brand and customer harm, operational continuity, and the lines AI adds. Model risk, responsible use thresholds, data boundaries for the fleet, and blast radius tolerance, which this model holds to one increment, one day, rollback proven.
The declaration becomes real in the bounded authority envelope. What a Decision Owner may accept alone, what escalates to the Flow Council, what stays with the officers. An appetite that lives in a policy document governs nothing. One that lives in envelopes governs every acceptance, every day, without a meeting. The guardrails say never. The appetite says how far.
Continuous Governance
The model does not weaken control. It moves control from inspection after the fact to enforcement inside the work. Policy constraints are enforced by the harness, the audit trail is a byproduct, and the Decision Owner accepts inside guardrails the Intent Council sets once per outcome. The discipline has a name, continuous governance, judgment injected constantly and in small doses at the point of work rather than summoned quarterly to a gate.
The Same Loop at Every Altitude
The pattern is fractal. Officers judge outcomes on their cadence. The councils judge the portfolio weekly and biweekly. Owners judge increments daily. The harness judges every push. Zoom into any level of the organization and the same loop is running, intent flowing down, evidence flowing up, judgment at the boundary, and the only thing that changes is the clock. That self-similarity is the reason a regulated enterprise can run daily cycles without losing its grip. Nothing is ungoverned at any scale. The governance is simply native to each scale instead of bolted above them all.
Still on the old path. Regulatory interpretation, risk appetite changes, and new external commitments remain Intent Council decisions on their existing cadence.
Execution
Fleet provisioning, AI tooling standards, model selection. This is new. It did not exist before because there was no agent fleet to provision, no model selection to make, and no AI tooling standard to set.
The Enterprise Decisions
Approved models, by use case. Fleet capacity provisioning and metering. The AI tooling standards Fleet Leads work within. The evaluation path for new capabilities as they emerge.
Which model fits which task changes monthly. The Intent Architect keeps that knowledge current, so approval decisions stay informed rather than folklore.
This is infrastructure investment, not project spending. The organizations that treat AI capability as a project will re-buy it every year. The ones that treat it as infrastructure will compound it.
Domain Judgment
Funding the Domain Knowledge Network. Encoding expertise at scale. Protecting institutional knowledge. This was always important. It is now load-bearing because when execution is no longer the constraint, domain context and timely judgment become the scarce resources.
The Funded Lines
Network membership is an additional, named, funded commitment of typically 20-30% of each expert's week. Budget a monthly two-hour network session for absorbing what came back and revising the shared context.
The health test of the network: expert hours per outcome trend down while coverage of their constraints trends up. That only happens if the Encode step is funded and the knowledge graph is maintained. Skip this investment and the network becomes a rota of interruptions.
Domain Judgment
Daily planning names the expert tomorrow's spec needs. Each morning the network reads the day's specs and dispatches. The rota is set at weekly Flow Council calibration, so expert availability is planned alongside capacity rather than begged for in the moment. Nobody is pulled reactively.
The network works on a push model rather than a pull model. Governance arrives as knowledge on the way in, rather than as a review queue on the way out.
The Rota Economics
Network membership is a named, funded 20 to 30% of each expert's week, planned at weekly calibration like any other capacity. An expert attends daily planning perhaps two days in five, when the next increment touches their specialty. The reactive alternative consumes the same hours, scattered, unplanned, and encoding nothing.
The Tell
The same question arriving month after month means the signal is not being read or the encode step is being skipped. A healthy network gets asked fewer questions every quarter, not more.
Domain Judgment
Every contribution leaves something behind that outlives the conversation. A check in the harness, a playbook update, context in the graph. Explaining it to the people in the room is necessary and not sufficient, because people rotate and memory fades.
If nothing outlives the conversation, the network is consulting rather than governing, and the same question comes back next month. The rule for every contribution: encode, not merely explain.
Enforce and Notice
Encoding stores enforcement, and it does not replace the expert. A check enforces what was foreseen. The guild notices what was not, and noticing is the part that stays human. The network that believes its encoded checks have replaced its people is one novel situation away from learning the difference.
The Health Test
Expert hours per outcome trend down while coverage of their constraints trends up. If hours are flat and the same questions keep returning, contributions are evaporating in the room, and the fix is the rule in this card's title.
Domain Judgment
A specialist works the spec directly with the Decision Owner and hands over the constraints and criteria their area requires. This is a working session, not a review meeting. The specialist typically spends 15-30 minutes.
They are checking correctness, not style. The criteria that touch their specialty are validated, and then those criteria are encoded into the harness. This is how domain knowledge enters the work ahead of the build and compounds over time.
Before, Not During
Knowledge that arrives after the fleet has started becomes rework. The same knowledge at spec time becomes a constraint the fleet builds against from the first line. The difference between those two sentences is most of the difference between governing and reviewing.
The Multiplier
The thirty minutes does not end when the expert leaves. The session leaves a harness check and a knowledge graph entry behind, and the check runs on every push, for every team, without the expert in the room. One conversation, enforced thousands of times.
Execution
Two Levels Operate Daily
Both the team level and the program level run on a daily cadence, but they serve different purposes.
Team (the build cycle): Specify, Build, Judge, Land. The team runs the one-day cycle that turns a spec into a landed increment.
Program (the governance cycle): The Flow Council attends daily planning across all teams. Blockers are resolved the same day. No team waits overnight for a decision the Flow Council can make now.
Beneath both, the individual level (the agent fleet) runs continuously. The fleet never stops.
The hour-by-hour shape of the build day is in the Build card. The short version: the spec is signed before the day starts, the fleet builds while the harness grows, and the day closes with demo, judgment, landing, and daily planning inside an hour.
Governance at the Daily Level
Governance answers three questions, and this model answers each continuously.
- Are we doing the right things? The Intent Council resets the Now / Next / Later horizons against landed evidence at the biweekly working session and the quarterly rebalance.
- Are we building them right? The Decision Owner accepts on a green harness every day, inside guardrails the Intent Council sets once per outcome.
- Are we learning? Every cycle's questions and edge cases return through the knowledge network and update the playbooks, the spec queue, and the roadmap.
Escalation Is Bounded and Fast
Any team can raise a blocker to the Flow Council on any day. The Flow Council resolves it or carries it to the Intent Council at the next check-in. No blocker outlives one cadence. Status, policy enforcement, and the audit trail are covered in the governance cycle card.
Direction
Portfolio Level: Flow Council Calibration
The portfolio operates on a weekly cadence. The Flow Council calibrates capacity against the Now horizon, rotates domain experts, and re-sequences work if the week's evidence warrants it.
At Weekly Calibration
- Capacity is re-planned against what actually exists this week.
- Domain expert rota is set for the following week, so availability is planned alongside capacity.
- The Now horizon is re-sequenced if the week's evidence warrants it.
- An Effort that has produced no landed increment for a week is raised whether or not the owner proposes closure.
- Release actions are minuted for every completed Effort.
The Weekly Rhythm
Capacity shifts week to week as people return from Efforts, go on leave, or are pulled into standing obligations. A plan older than a week is fiction. The weekly calibration is where the plan is rebuilt against reality.
Direction
Division Level: Flow Council Checks In to the Intent Council
The division operates on a biweekly cadence. The Flow Council checks in to the Intent Council at the strategic working session. Evidence is reviewed and direction is reset. This is where the Intent Council resets the Now / Next / Later horizons against landed evidence.
Status Is Read, Not Written
Nobody compiles a status deck. The evidence ledger is the status, and governance forums open by reading it rather than hearing it summarized. A forum that cannot read the evidence directly has an instrumentation gap, and closing that gap is Flow Council work.
Still on the Old Path
Regulatory interpretation, risk appetite, and new external commitments remain Intent Council decisions on their existing cadence. The model does not compress these, and claiming otherwise is how transformations lose credibility with a second line of defense.
For a Risk Audience
Lead with evidence rather than speed. This model produces more evidence, more often, at a finer grain, and with clearer attribution than the process it replaces.
Direction
Board Level: Pulse Check Against Strategic Outcomes
The board operates on a monthly cadence. Leaders review portfolio progress against the enterprise strategic objectives. This is where the portfolio's progress is measured against the declared outcomes that sit above the portfolio.
The monthly pulse check is not a governance gate. It is a reading of evidence at the level where strategic outcomes are owned. The evidence ledger makes this possible without a status deck.
A Reading, Never a Gate
The pulse reads the model's mechanics, owner presence, the Confirm, Amend, Replace ratio, blocker resolution time, capacity released back to the pool. It does not read velocity, story points, or utilization, because those measure motion rather than judgment. And it is never punitive. The moment a metric is used to judge people, the Replace rate drops to zero and the blockers stop being raised, which blinds the very instrument leadership is reading.
Direction
Roadmap rebalance. Now / Next / Later horizons shift with what the portfolio learned. This is where the Intent Council makes the largest strategic adjustments, moving outcomes between horizons based on accumulated evidence rather than forecasts.
Still on the old path. Regulatory interpretation, risk appetite, and new external commitments remain Intent Council decisions on their existing cadence.
The Rebalance Mechanics
Prune Later, re-sequence Next, and move outcomes between horizons on accumulated evidence. Movement happens at Effort boundaries, because teams are stable within an Effort and reform only between them, which yields roughly a dozen real reallocation points a year instead of one annual big bang. The horizons are states of commitment, not loose estimates of time.
Control plane
Purpose, work, ownership, constraints, and relationships live in one lasting graph. Now / Next / Later is a portfolio projection of that graph, not a separate roadmap database.
The Intent Council sets direction and the Flow Council sequences capacity. Every action retains a trace to the outcome it serves.
One Source of Purpose
The roadmap, the boards, and the operations views are projections, read models over the same graph. Edits happen in the graph, never in the views, which is why two leaders reading different screens are still reading the same truth. Nobody reconciles decks because there are no decks to reconcile.
The Trace, Tended
Untended, intent topology does what untended structure always does. Outcomes overlap, portfolios pursue contradictory conditions without knowing it, and constraints get restated at each level until the daily work enforces something the officers never said. The graph is tended so that any Tuesday build walks back to a boardroom sentence in under a minute.
Control plane
Domain knowledge, policy sources, decision history, and prior evidence are connected to the intent that needs them. Context is assembled from purpose and permission, not from whichever documents an agent happens to retrieve.
Each expert's contribution can shape an outcome, narrow an authority envelope, become a spec criterion, or become a harness check. Every cycle returns learning to the graph.
Context Packs, Metered
Context arrives as curated packs, the systems, the vocabulary, the edge cases, the history a task genuinely needs. More context is not better context, and in token terms it is not even neutral, because every unneeded document taxes thousands of calls a day. Context, not output, is the expensive half of the fleet bill, and curation is the cost control.
Evidence With a Date
Customer truth is stored with its date visible, because it decays in months where policy decays in years. A brief citing last spring is making a different claim than one citing last week, and the graph makes the difference impossible to miss.
Control plane
Intent coordinates authorized human and agent capacity around declared outcomes. It determines what is ready, who or what may act, which context travels with the action, and where human judgment is required.
Execution can happen in Intent or in external tools. Those tools perform the work; Intent remains the authority for why it exists and what evidence must return.
Spawning, Governed
Fleets are not fixed formations. Agents spawn agents when work splits, and a formation can spike to scores of agents under one orchestrator. Every spawned agent inherits the same context admission and the same constraints, and fleet capacity is metered, so the Effort that quietly doubles its agent count surfaces at weekly calibration instead of on the invoice.
The Human in the Formation
One to three Fleet Leads drive each crew, intervening two to four times a day, each time for a named reason. Zero interventions means nobody is watching. Ten means the context is too thin to build from.
Control plane
Every result carries a proof chain: the intent it served, the authority under which it ran, the applicable criteria, the verification evidence, the acceptance decision, and who made it.
The harness contributes repeatable proof where checks can be automated. It does not replace the accountable human who decides whether the result should be accepted. Status is read from that connected evidence.
The Court Test
No enterprise gets to tell a regulator, a customer, or a court that the machine was the one who understood. The ledger exists so that sentence never has to be spoken. Every consequential result names the human who accepted it and the evidence they accepted it against.
Audit as Byproduct
The trail is written continuously by the act of working, allocation by allocation, acceptance by acceptance. It is stronger than anything reconstructed at project close, and it costs nothing extra to produce, because it is not a second activity. It is the first activity, recorded.
Control plane
Roles, permissions, constraints, escalation paths, and judgment gates travel with the work. Some boundaries can be enforced by access controls or harness checks. Others require an explicit human decision.
Intent keeps both kinds connected to the outcome and records who authorized each consequential action. Governance moves with execution instead of inspecting it later.
The Envelope, Once
Authority is written down once per outcome. The categories the owner accepts unilaterally, the ones that escalate, and the ones reserved for the councils. Machines prove the bounds that can be checked. Humans remain accountable for the decisions inside them.
The Apparatus, Arrived
Executive decisions have always traveled wrapped in staff work, controls, and audit. The working level never had that apparatus, which is the real reason authority pooled at the top. The envelope, the harness, and the ledger are that apparatus finally arriving where the work happens. Nobody is asked to trust more. Trust just got cheaper.
Domain Judgment
Humans direct the system. They choose what is worth building, define what right means, supply the context, and stay accountable for what is accepted. AI produces against that direction at machine speed.
The Human Share
- Choose the outcomes that matter
- Engineer the context the fleet works from
- Define success and constraints
- Resolve ambiguity and trade off
- Accept value, stay accountable
The People Question
The work changes shape rather than disappearing. Judgment, domain knowledge, and accountability all become more valuable as production becomes cheaper, and expertise is not discarded. What thins out is coordination that exists only to manage handoffs. Which individuals land in which role is a conversation for the organization to have.
The New Accountabilities
The model creates three roles (the Decision Owner, the Fleet Lead, and the Intent Architect), two seats (Intent Council and Flow Council membership), and one funded commitment (the Domain Knowledge Network expert). Six named accountabilities, and surprisingly little net-new headcount.
Execution
AI agents are powerful implementers with no judgment about what should be built. They draft, implement, prove, and trace at machine speed. The fleet produces far more implementation per hour than a person can, which raises the cost of ambiguity if the spec is skipped.
The Machine's Share
- Drafts the spec with the owner
- Writes and runs the harness in CI
- Surfaces knowledge and dependencies
- Preserves evidence and traceability
No Memory, No Stake
Every session starts new. The instances that built yesterday have no memory of building it and no stake in what happens next, which is why the theory of the system stays with the humans. The fleet is a brilliant implementer of stated intent and a confident implementer of misunderstood intent, and it cannot tell the difference. The people on this chart exist at exactly that seam.
The Formation
The fleet is a soft count. Agents spawn agents when work splits, and formations swell to scores under one orchestrator when the day calls for it, then thin again by night. Capacity is metered so the swelling is a calibration line, not a surprise.
Cross-cutting
The model replaces structures that exist to manage the old constraint (scarce delivery capacity). These structures hold back abundant delivery capacity rather than releasing it.
- Sprint planning: Replaced by the one-day cycle and daily planning
- Program governance: The program layer goes away, not on a diet. The portfolio swarms crews to Efforts directly, forming at Effort boundaries and re-planned at weekly calibration, a dozen times a quarter where a program plan managed one a year. The coordination the layer existed for is carried by the Flow Council's daily, weekly, and biweekly cadence, and its people go where the work went, portfolio operations and the intake machinery
- Role-based assignment: Replaced by fluid formation from the capacity pool
- Knowledge hoarding: Replaced by the Domain Knowledge Network's Inject / Encode / Return flow
- Status reporting: Replaced by the evidence ledger that is read, not written
- A separate QA phase: Replaced by the harness running in CI on every push
- Demo-only acceptance: Replaced by acceptance against evidence and a green harness
Direction
The model preserves everything a regulated business cannot lose. It strengthens rather than weakens each of these.
- Strategic alignment: The Intent Council resets horizons against evidence, biweekly and quarterly
- Quality judgment: The Decision Owner accepts daily on evidence, inside bounded authority
- Daily accountability: Every day ends in an accepted increment or a named blocker
- Regulatory safety: Policy constraints are enforced by the harness in CI
- Audit trail: Every increment carries its spec, harness results, acceptance decision, and who made it
- Test coverage as a contract: The harness compounds over time, proving each new increment against all prior constraints
Direction
How Intake Works
A sponsored request arrives through one front door. The sponsoring officer approves the request and commits to releasing the Decision Owner. These happen one time per outcome.
Intake deserves care because it is where two different officer groups meet. Demand originates in the areas, and technology is one of them, raising platform, security, and modernization work through its own officers. Each area holds its own officer group. A request is approved by its own sponsoring officer before the portfolio ever sees it. Nothing arrives unowned and nothing arrives unsponsored.
That sponsorship is not a formality. The sponsoring officer is the only person who can release a business expert from their day job, so their approval is simultaneously the commitment of a Decision Owner. This is what converts No Owner No Now from a rule into something enforceable. Without it, the Flow Council would be asking teams to find owners it has no authority to free.
Keep the two officer groups distinct in conversation. Sponsoring officers decide that something is worth doing and fund the person to own it. The Intent Council decides where it sits against everything else in the portfolio. Confusing the two is how intake turns back into a queue of unfunded good ideas.
Empowerment
| Step | Decision Rights |
|---|---|
| Intake | Sponsoring officer of the demand source |
Direction
At Triage
The Flow Council sets value, priority, and horizon. Every sponsored request enters the same front door and is triaged against the portfolio rather than against the area it came from. If it clears the No Owner No Now gate, the Flow Council names a Decision Owner and commits capacity.
The Three Zones of the Lifecycle
The lifecycle has three zones. Conflating them is the most common way this model gets misread as a waterfall.
Zone 1, enters once. Intake, Triage, Form. A sponsored request arrives, the Flow Council sets its value, priority, and horizon, and if it clears the No Owner No Now gate the Flow Council names a Decision Owner and commits capacity. These happen one time per outcome.
Zone 2, repeats every day. Specify, Build, Judge, Land. This is a loop and not a sequence of gates. It turns once per day for as long as the outcome takes, which may be four days or four months. Daily planning closes each turn and sets the next spec.
Zone 3, closes once. Release. The outcome is met and the Flow Council returns the people and the fleet to the pool.
Empowerment
| Step | Decision Rights |
|---|---|
| Triage | Flow Council |
Direction
Forming the Team
A Decision Owner is named and capacity is committed. The Flow Council forms the team: typically two or three humans plus their fleet. A deputy is named at formation for short absences, not found on the morning someone calls in sick.
Formation is where the Decision Owner's bounded authority envelope is set by the Intent Council. The envelope names the guardrails, the risk appetite, and the categories that must escalate.
At Formation
Names the Decision Owner and confirms their release at the committed level. Assigns a Fleet Lead. Commits agent fleet capacity. Names a deputy for short absences. Sets the bounded authority envelope with the Intent Council.
Empowerment
| Step | Decision Rights |
|---|---|
| Form | Flow Council |
Domain Judgment
Shipping Is a Destination Decision
Shipping is a destination decision. It is never a question of whether anything shipped. Every day ends in one of three destinations, and the destination is determined by clearance, not by readiness.
Preferred: Same-Day Production
Where regulatory clearance and the delivery pipeline both allow it, the increment reaches production and real users the same day. This is the preferred destination and the one the model optimizes for.
The Clearance Test
The clearance test is run once per outcome and not per increment. It asks three questions:
- Does the change class have an approved deployment path?
- Does the control layer of the harness cover the applicable policy constraints?
- Is rollback automatic and proven?
Where all three hold, ship. Where any one fails, the increment lands in the hands-on environment until the clearance gap is closed.
Establishing clearance for a class of change is high-value Flow Council work, because it converts every future increment in that class from a queued release into a same-day one. This is infrastructure work, not project work, and it compounds.
The Floor: Always, a Hands-On Environment
Where same-day production is not available, the increment lands somewhere stakeholders can open it and use it themselves. This is the floor, and it is always available.
This environment must meet three requirements:
- It has realistic data, not synthetic or sanitized data that hides the edge cases
- It is reachable without a scheduled session, so stakeholders can form opinions on their own time
- It is current within one build day, so what stakeholders see reflects what was just accepted
Never a slide. Never a status report. Never a recorded walkthrough as a substitute. The point is that a stakeholder can form an independent opinion by using the thing, which is the only reliable way to surface a misunderstanding before it becomes expensive.
Or Learn (Ship-or-Learn)
The increment is not accepted, the blocking constraint is named that day, and it redirects tomorrow's spec. Nothing sits in an ambiguous state overnight.
When a Replace happens and the new direction is not yet clear, do not force a build day. Run tomorrow as a spec-and-explore cycle. The fleet investigates, prototypes throwaway options, and gathers what the owner needs to decide. The day still ends with something in someone's hands, but the artifact is a decision rather than an increment. This is the "learn" branch of ship-or-learn, and it is a legitimate, planned outcome rather than a lost day.
Empowerment
| Step | Decision Rights |
|---|---|
| Land | Decision Owner, inside the clearance rules |
Direction
How an Effort Ends
Release depends on someone declaring the outcome met, and Efforts drift when nobody owns that call. The Decision Owner proposes closure when the outcome's acceptance criteria are satisfied, and the Flow Council confirms it at weekly calibration. Two people are involved because an owner close to the work will sometimes keep going past the point of value, and the Flow Council holds the portfolio view that catches it.
Closure is a decision with a date, recorded like any other. An Effort that has produced no landed increment for a week is raised at calibration whether or not the owner proposes closure, because that pattern usually means the outcome was reached, the Effort was blocked, or it should never have entered Now.
Capacity Returns to the Pool
The moment an outcome is accepted, the people and the fleet return to the pool, and the Flow Council redeploys them to the next Effort, usually within the same week.
Release is the half most organizations skip, and skipping it is what rebuilds standing teams. If capacity never returns to the pool, within two quarters you have permanent teams with new labels and the model has failed silently. Make release an explicit, minuted Flow Council action with a date, not something that happens by drift.
Empowerment
| Step | Decision Rights |
|---|---|
| Release | Flow Council |
Direction
The Concept
Work does not arrive unowned. An officer stands behind every request before the portfolio sees it. This dual commitment (sponsorship + Decision Owner release) is what makes the No Owner No Now gate enforceable. Without it, the Flow Council would be asking teams to find owners it has no authority to free.
Keep Two Officer Groups Distinct
Sponsoring officers decide something is worth doing. The Intent Council decides where it sits against everything else. Confusing the two is how intake turns back into a queue of unfunded good ideas.
Direction
The Pool Model
The Flow Council holds one pool of people and agent fleets for the whole portfolio. Capacity is planned and released, never allocated to a standing team. Standing teams rebuild the old constraint because they create ownership claims on people and systems that prevent the Flow Council from moving capacity to the highest-value work.
Plan / Commit / Release
Each week the Flow Council sizes capacity against the Now horizon. Capacity goes to an Effort for as long as it needs it. The moment an outcome is accepted, people and fleet return to the pool. Release is the half most organizations skip, and skipping it is what rebuilds standing teams. If capacity never returns to the pool, within two quarters you have permanent teams with new labels and the model has failed silently.
Direction
The Structure
Two groups, one line of authority. The Intent Council is the officer body that sets direction. The Flow Council is the governing body closest to the work. Authority is delegated down once, evidence and escalations travel back up on cadence. Getting the boundary wrong is costly in both directions.
Getting the Boundary Wrong
If the Intent Council makes work decisions, everything queues behind an officer calendar and the daily cycle dies. If the Flow Council makes strategy decisions, the portfolio drifts from the organizational objectives and nobody notices until a quarterly review.
Direction
Delegated Once
Authority is delegated down from the Intent Council once, and evidence and escalations travel back up on cadence. A blocker the Flow Council cannot resolve goes to the Intent Council at the next check-in, never later than one cadence.
The Boundary
The Intent Council sets direction, standards, and risk appetite. The Flow Council makes the daily work decisions. This boundary is what lets the model run at the speed of work rather than the speed of an officer calendar.
The Apparatus Law
Authority in an enterprise flows to wherever the apparatus for exercising it exists. Executive decisions travel wrapped in staff work, controls, and audit, and for twenty years the working level had none of that, so authority pooled at the top and committees stood in below. The envelope, the harness, and the ledger are the apparatus finally arriving at the work, which is why this delegation holds where earlier ones quietly retracted.
Direction
Prioritized outcomes, decision-ready briefs, and acceptance standards flow from the Intent Council through the Flow Council to the teams. Direction meets the work when the work needs it, not when the calendar permits.
The Downward Flow
- Prioritized outcomes from the Now / Next / Later horizons
- Decision-ready briefs that the Flow Council prepares at triage
- Acceptance standards that the Intent Council sets once per outcome
The Authorship Cascade
Meaning survives the trip down because every altitude has an author, never a translator. Officers author outcomes. Decision Owners author briefs and decompose them into Effort specs. Fleet Leads author the technical specs the fleet executes. Decomposition by authors is the discipline, and it is the reason what the fleet receives is still what the enterprise meant.
The Trace Test
Run it in reverse to check the health of the flow. Any Effort on this chart walks back to the outcome it serves in under a minute. When that walk takes an afternoon and a meeting, the cascade has silently become translation.
Direction
Daily evidence and demos, escalations with options, and portfolio learning flow up from teams through the Flow Council to the Intent Council. Status is read from the evidence ledger, not compiled into decks.
The Upward Flow
- Daily evidence and demos proving each increment against the spec
- Escalations with options when a team hits something outside the Decision Owner's envelope
- Portfolio learning that changes what the next team receives
Status Is Read, Not Written
Nobody compiles a status deck in this model. The evidence ledger is the report, and each level reads it at its own altitude. The daily demo for the team, the calibration view for the Flow Council, the outcome trajectory for the officers. The hours that used to go into decks go into the work the decks were about. The people who used to compile them land well here too, running the ledger views and the portfolio operations the councils read.
The Escalation Contract
Escalations travel up with options attached, never as bare problems, and nothing escalated outlives one cadence. A blocker the Flow Council cannot clear reaches the Intent Council at the next check-in with the tradeoffs already framed for a decision.
Cross-cutting
Intent flows down, evidence flows up, judgment at the boundary. This is the circulatory system of the model.
The Loop This Closes
The gap between bands is not a boundary. It is a channel. Direction from the Intent Council reaches teams through the Flow Council without a committee or a meeting. Evidence from teams reaches the Intent Council through the evidence ledger and the biweekly check-in. The daily cycle runs because nothing in this channel queues.
Continuous Governance
The discipline running through this channel has a name. Judgment is injected constantly and in small doses at the point of work, daily acceptance, weekly calibration, biweekly check-ins, a monthly pulse, a quarterly rebalance, instead of being summoned quarterly to a gate.
The Fractal
Zoom into any level and the same loop is running. Officers judge outcomes, councils judge the portfolio, owners judge increments, the harness judges every push. Intent down, evidence up, judgment at the boundary, and the only thing that changes is the clock. Nothing is ungoverned at any scale, because the governance is native to each scale.
Direction
How Governance Travels
Governance travels with the work instead of waiting at stage gates. The model does not weaken control. It moves control from inspection after the fact to enforcement inside the work. The cycle runs continuously: the Intent Council sets direction, the Flow Council directs, teams build, and the network validates.
The Three Questions
Are we doing the right things? The Intent Council resets the horizons against landed evidence, biweekly and quarterly.
Are we building them right? The Decision Owner accepts on a green harness every day, inside guardrails the Intent Council sets once per outcome.
Are we learning? Every cycle's questions and edge cases return through the network and update the playbooks, the spec queue, and the roadmap.
Status Is Read, Not Written
Nobody compiles a status deck. The evidence ledger is the status, and every governance forum opens by reading it rather than hearing it summarized. A forum that cannot read the evidence directly has an instrumentation gap, and closing that gap is Flow Council work.
Policy Constraints Are Enforced by the Harness
The control layer checks that constraints hold and that the audit trail is written, on every push. This is a stronger evidentiary position than a phase-gated process that produces documents describing intent rather than proof of behavior.
The Audit Trail Is a Byproduct
Every increment carries its spec, its criteria, its harness results, the acceptance decision, and who made it. The audit trail is produced by doing the work, not by documenting the work separately.
Escalation Is Bounded and Fast
Any team can raise a blocker to the Flow Council on any day. The Flow Council resolves it or carries it to the Intent Council at the next check-in. No blocker outlives one cadence. The Flow Council lead who owns the blocker is named publicly, so accountability is clear.
Evidence Is the Shared Currency
Every node in this cycle produces and consumes evidence. Direction flows clockwise, evidence flows counterclockwise, and the cycle turns continuously rather than at scheduled intervals. The cadences are:
- Continuous (Individual): The agent fleet never stops. Harness runs on every push.
- Daily (Team): The one-day cycle: specify, build, judge, land.
- Daily (Program): The Flow Council attends daily planning across all teams. Blockers are resolved the same day.
- Weekly (Portfolio): Flow Council calibration. Capacity is re-planned, domain experts are rotated, the Now horizon is re-sequenced.
- Biweekly (Division): The Flow Council checks in to the Intent Council. Evidence is reviewed and direction is reset.
- Monthly (Board): Pulse check against strategic outcomes.
- Quarterly: Full roadmap rebalance. Horizons shift with what the portfolio learned.
Still on the Old Path
Regulatory interpretation, risk appetite, and new external commitments remain Intent Council decisions on their existing cadence. The model does not compress these, and claiming otherwise is how transformations lose credibility with a second line of defense.
Direction
Governance Answers Three Questions Continuously
The model does not weaken control. It moves control from inspection after the fact to enforcement inside the work. Governance answers three questions, and this model answers each continuously rather than at periodic review boards.
1. Are We Doing the Right Things?
The Intent Council resets the Now / Next / Later horizons against landed evidence at the biweekly working session and the quarterly rebalance. This is the strategic question, and it is answered by reading evidence rather than hearing reports.
The mechanism: At the biweekly strategic working session, the Flow Council presents landed evidence to the Intent Council. The Intent Council reads the evidence ledger and decides whether the horizons need resetting. At the quarterly rebalance, the full portfolio is reviewed and horizons shift with what was learned. Status is read, not written. Nobody compiles a status deck.
2. Are We Building Them Right?
The Decision Owner accepts on a green harness every day, inside guardrails the Intent Council sets once per outcome. This is the quality question, and it is answered every single day.
The mechanism: The harness runs on every push, proving shape, behavior, failure paths, and policy compliance. The Decision Owner accepts only against a green harness. The network validates that domain constraints are met. Policy constraints are enforced by the harness in CI, and the audit trail is a byproduct rather than an exercise. Every increment carries its spec, its criteria, its harness results, the acceptance decision, and who made it.
3. Are We Learning?
Every cycle's questions and edge cases return through the knowledge network and update the playbooks, the spec queue, and the roadmap. This is the learning question, and it is what makes the model compound rather than repeat.
The mechanism: Questions and edge cases flow back from teams into the Domain Knowledge Network. The network updates the playbooks the next team will receive. The harness accumulates checks that outlive individual Efforts. The monthly network session absorbs what came back and revises the shared context. The roadmap shifts as the portfolio learns what works.
Continuous, Not Periodic
These are not periodic questions asked at a review board. They are answered continuously, by different actors, at different cadences, all feeding the same evidence ledger. The first is answered biweekly and quarterly by the Intent Council. The second is answered daily by every Decision Owner. The third is answered on every cycle by every team and monthly by the network as a whole.
Still on the Old Path
Regulatory interpretation, risk appetite, and new external commitments remain Intent Council decisions on their existing cadence. The model does not compress these, and claiming otherwise is how transformations lose credibility with a second line of defense.
For a risk audience, lead with evidence rather than speed. This model produces more evidence, more often, at a finer grain, and with clearer attribution than the process it replaces.
Direction
The Intent Council resets the horizons against landed evidence, biweekly and quarterly. This is the strategic question, and it is answered by reading evidence rather than hearing reports.
How It Is Answered
At the biweekly strategic working session, the Flow Council presents landed evidence to the Intent Council. The Intent Council reads the evidence ledger and decides whether the Now / Next / Later horizons need resetting. At the quarterly rebalance, the full portfolio is reviewed and horizons shift with what was learned.
Domain Judgment
The Decision Owner accepts on a green harness every day, inside guardrails the Intent Council sets. This is the quality question, and it is answered every single day.
The Daily Answer
The harness runs on every push, proving shape, behavior, failure paths, and policy compliance. The Decision Owner accepts only against a green harness. The network validates that domain constraints are met. The evidence is recorded in the ledger for every governance forum to read.
The Demo Cannot Carry It
A demo shows one path through the system, walked once, on a good day. The harness checks every path, every push. An owner who accepts on a red harness because the demo looked right has taught the team the harness is optional, and within two weeks the model has quietly reverted to demo-based acceptance, which is the process this replaced.
Domain Judgment
Every cycle's questions and edge cases return through the network and update the playbooks, the spec queue, and the roadmap. This is the learning question, and it is what makes the model compound rather than repeat.
The Compounding Answer
Questions and edge cases flow back from teams into the Domain Knowledge Network. The network updates the playbooks the next team will receive. The harness accumulates checks that outlive individual Efforts. The roadmap shifts as the portfolio learns what works.
The Replace-Rate Diagnostic
Healthy learning shows up in the numbers. Confirm on most days, Amend on 20 to 30%, Replace on 5 to 15%. A Replace rate stuck at zero means the portfolio is building things so well understood the model is wasted on them. Persistently above 30% means the slices are bigger than the team's knowledge. Replace days are not failures. They are expensive lessons arriving early, which is the entire point of shipping daily.
Cross-cutting
The Evidence Ledger Is the Status
Nobody compiles a status deck. The evidence ledger is the status. Governance forums open by reading it, then make calls. A forum that cannot read the evidence directly has an instrumentation gap, and closing that gap is Flow Council work.
Inside the Ledger
Every increment carries its spec, its criteria, its harness results, the acceptance decision, and who made it. This is a stronger evidentiary position than a phase-gated process that produces documents describing intent rather than proof of behavior. The audit trail is a byproduct, not an exercise.
Direction
Bounded and Fast
Any team can raise a blocker to the Flow Council on any day. The Flow Council resolves it or carries it to the Intent Council at the next check-in. No blocker outlives one cadence.
How It Works
A Flow Council lead attends each team's daily planning. Blockers raised there are resolved or escalated the same evening. If the Flow Council cannot resolve a blocker, it goes to the Intent Council at the biweekly working session. The Flow Council lead who owns the blocker is named publicly, so accountability is clear.
Cross-cutting
The Third Role
The Intent Architect engineers how intent moves through the organization. The written artifacts, quality standards, and flows that turn strategy into work machines can run and people can judge. What the enterprise architect is to systems, the Intent Architect is to what the organization means.
The role runs on two verbs. They teach, so authors at every altitude learn what good means through worked examples rather than mandates. And they hold the bar, defended, revised only by evidence, never lowered for convenience. Teaching without the bar produces drift. The bar without teaching produces a gate. The role is the two together.
Seven Concerns
- Intent topology: outcomes decompose cleanly, nothing contradicts, the trace walks
- Checkability: an adverb in an acceptance criterion is a defect
- Context economics: global and local context, curated for correctness and token cost
- The model landscape: which model fits which task, kept current as it shifts monthly
- Authority boundaries: the envelope is part of the intent, not process bolted on
- Evidence semantics: green and right are different words, and the proof science is still maturing
- The conversation record: the exchanges between people and the system, treated as the asset they are
The Never List
Never accepts work. Never allocates capacity. Never sets risk appetite. Never directs the fleet. Those belong to the Decision Owner, the Flow Council, the Intent Council, and the Fleet Lead. The moment work waits on the Intent Architect's approval, the role has failed.
Mature ratio: one Intent Architect per three to five teams. Start with one, prove the craft on real Efforts, and grow the guild from inside.
Cross-cutting
One Unbroken Thread
Every daily spec opens with a one-sentence trace to the outcome its Effort serves. The outcome is the objective. There is no third layer between the work and the intent. The test is concrete: any day's work walks back to its outcome in under a minute, and orphaned work gets named in the open at the weekly review.
The Drift It Prevents
Untended, intent topology does what untended structure always does. Outcomes overlap, portfolios pursue contradictory conditions without knowing it, and constraints get restated differently at each level until the daily work enforces something the officers never said. The trace is how the organization knows, on any given day, that the work across the portfolio connects to what was declared.
The Intent Architect tends the thread. The councils and owners author within it.
Direction
Two Councils, One System
A directing intelligence, not a review board. It meets the work, not the calendar. Portfolio Direction is where the Intent Council and Flow Council operate as one continuous governance system.
The Difference
Traditional portfolio review boards meet monthly or quarterly, hear summaries, and make decisions against stale information. Portfolio Direction in this model runs on evidence that arrives daily, decisions that happen within hours, and a roadmap that resets when the evidence warrants it rather than when the calendar permits.
Two Tiers
The Intent Council sets direction. The Flow Council runs the work. Authority is delegated down once, evidence flows back up on cadence. The two tiers together form the direction layer that replaces program governance and periodic portfolio review boards.
The Intent Architect anchors beside the Flow Council, serving every team and sitting on none, holding the quality bar for the intent the councils and owners author.
Execution
Execution Units
Small effort teams direct fleets of AI agents. Judgment stays human. Production does not. The humans are a crew, two or three of them wrapped around a fleet, and the unit holds together for the life of one Effort. A crew may also carry a learning seat, a code-fluent junior reading at altitude beside the Fleet Lead, so the theory of the system outlives its holders.
The Size of a Crew
When AI handles production, the human contribution is judgment, domain knowledge, and direction. Those scale with expertise, not headcount. A team of two skilled humans directing a fleet produces more than a team of twelve managing each other's handoffs.
Three Roles
The Decision Owner owns the outcome and accepts the work. The Fleet Lead holds technical judgment and directs the agents. The AI Agent Fleet implements at machine speed. Nobody else needs to be on the team.
Domain Judgment
The Real Bottleneck
A new layer of the organization. When execution stops being the constraint, domain context becomes the scarce resource. This layer exists because scarce resources need structure.
The Gap It Fills
Every prior operating model assumed execution was the constraint and organized around it. When AI makes execution abundant, the constraint moves to domain knowledge: knowing what to build, what constraints apply, what good looks like. The Domain Knowledge Network is the structural answer to that shift.
How It Works
A guild of domain experts (policy, compliance, risk, data, operations, business analysis) floats across the portfolio. Knowledge is injected at spec time, encoded into the harness, and returned as learning. The network compounds instead of repeating itself.
Domain Judgment
Governance arrives as knowledge on the way in, rather than as a review queue on the way out. This is the fundamental shift in how domain knowledge operates in this model.
Three Verbs
The network's knowledge governs in three verbs. It is injected at spec time before the fleet starts, encoded into the harness where it enforces itself on every push, and returned as learning that changes what the next team receives.
The Scale of the Change
In a traditional model, domain experts review output after it is built. In this model, their knowledge enters the work before the build starts and enforces itself automatically after they leave the room. That is the difference between governing and reviewing.
Domain Judgment
The Meaning
The Decision Owner accepts inside the guardrails and risk appetite the Intent Council sets, and escalates to the Flow Council outside them. Bounding it is what makes real acceptance authority safe to grant in a regulated business.
The Default Envelope
Accept unilaterally: Functional behavior, user experience, internal process changes, anything reversible within one cycle, and anything where the harness is green and no policy constraint is touched.
Escalate to Flow Council: Changes that touch a policy constraint, anything affecting an external counterparty commitment, changes to regulated decision logic, spend above a stated threshold.
Intent Council decides: Regulatory interpretation, risk appetite changes, anything creating a new external commitment.
The envelope is what makes daily acceptance safe in a regulated business. Without it, either everything escalates and the cycle dies, or nothing escalates and you have an audit finding.
Direction
Five Inputs
Five inputs flow from the enterprise into the portfolio. Three are familiar from Lean Portfolio Management: strategic outcomes, investment funding, and governance. Two are new because the constraint moved to human judgment: AI capability investment and knowledge investment.
The Two New Lines
AI capability investment did not exist before because there was no agent fleet to provision. Knowledge investment was always important but was implicit. When execution stops being the constraint, domain context becomes the scarce resource, and scarce resources need explicit funding.
Domain Judgment
Three Destinations
Every day ends in one of three places. Shipped to users if cleared. Landed in a hands-on environment if not. Or learned from, with the blocker named and tomorrow's spec redirected. Never a slide. Never a status report.
Shipping Is a Destination Decision
It is never a question of whether anything shipped. The question is where it lands. The preferred destination is all the way to users. The floor is always a hands-on environment where stakeholders can use it. The learn branch names the blocker and redirects the next spec.
Cross-cutting
The Core Thesis
Prior operating models organized around delivery capacity. This one organizes around knowledge throughput. The scarce resources are domain context and timely judgment, not developer hours.
The Change
As delivery time for a unit of work falls toward zero, the constraint does not disappear. It moves to the slowest remaining human step: deciding what should be built, judging whether what came back is right, and supplying the domain knowledge needed for either call.
An organization built around the old constraint cannot feel the benefit. Planning increments, standing teams, stage-gate review, and sprint ceremony all exist to schedule and coordinate scarce delivery capacity. Point them at abundant delivery capacity and they hold it back rather than release it.
A Living Artifact
This comes out of years of direct work on organizational flow. Treat it the way the model treats its own work. Run it, watch what happens, and feed what you learn back in. A model that cannot be corrected by the evidence it produces is an oracle. This is not one.
Domain Judgment
Knowledge is pushed into the work before teams stall. Questions and patterns flow back. This is the channel between execution and the domain knowledge network.
The Push Model
The network works on a push model rather than a pull model. Daily planning names the expert tomorrow's spec needs. Each morning the network reads the day's specs and dispatches. Nobody is pulled reactively. A team that has to pull for domain knowledge is a team that stalls.
The Guild Behind the Channel
The seats on the guild are knowledge streams, not job titles. One person often carries two or three, a compliance lead who also holds policy, an analyst who holds domain and data, and a small guild of three or four people can cover every stream between them. The floor is that every stream has at least one named holder.
The Health Test
Expert hours per outcome trend down while coverage of their constraints trends up. Both flat means the encode step is being skipped and the channel has become a consulting line.
Execution
Outcome briefs, domain context, and guardrails and standards flow into the team at the start of each Effort and each daily cycle.
Arrivals
- Outcome briefs prepared by the Flow Council at triage
- Domain context injected by the knowledge network at spec time
- Guardrails and standards set by the Intent Council and encoded into the harness
The Standard of Arrival
Work does not start until the arriving set is complete. A signed spec, a curated context pack, and a named expert for anything the spec touches. An Effort that starts on a partial set is not moving faster. It is importing the rework it will do in week three.
A Hub, Not a Mesh
The arrivals are also how the fleet coordinates. Agents do not negotiate with each other. They converge on the same spec and the same harness, so what each one builds against is exactly what was authored, with no telephone game between altitudes.
Execution
Working increments, evidence packs, and questions and edge cases flow out from the team every day.
Departures
- Working increments that land in someone's hands or in a hands-on environment
- Evidence packs recorded in the ledger with spec, harness results, and acceptance decision
- Questions and edge cases that return to the knowledge network and update the playbooks
The Ledger Entry
Every departure is recorded as it leaves. The increment, the spec it satisfied, the harness results, the acceptance decision, and the person who made it. The audit trail is a byproduct of working, not a document assembled later, which is why it is stronger than anything compiled at project close.
The Fourth Departure
When the outcome is met, capacity departs too. People and fleet return to the pool, minuted with a date. Zero returns over a quarter while Efforts complete is the tell that standing teams are quietly reforming.
Domain Judgment
Domain context, policy constraints, and validation criteria flow from the knowledge network into the work at spec time, before the fleet starts.
The Push Model
Each morning the network reads what the day's specs require and connects the right expert to the right team before anyone has to ask. Governance arrives as knowledge on the way in, rather than as a review queue on the way out.
The Amplification Stake
Machine speed turns this flow from efficiency into survival. A fleet propagates whatever enters it with perfect fidelity, including a wrong assumption, so an error injected at spec time reaches the whole formation before lunch. The only place to catch it cheaply is before the build, which is exactly where the network stands.
Dated, Not Assumed
Customer evidence enters the same way policy does, cited and dated in the brief. A constraint nobody can source is recorded as an assumption to be tested, not a fact to build on.
Domain Judgment
Questions and edge cases, new patterns, and updated playbooks flow back from the work into the knowledge network after each cycle.
The Point of the Return
Without the return channel, the network falls back to one-way injection, which is helpful but not self-improving. The return flow is what separates a knowledge network from a staffing rota. The network compounds instead of repeating itself.
The Return Set
Four things flow back. Edge cases become new harness checks. Policy interpretations, once made, become constraints the next team inherits instead of re-deriving. Customer signal, support themes, usage patterns, and acceptance evidence, lands in the graph with its date attached. And patterns of misunderstanding between intent and output show where the shared context is thin.
The Monthly Absorption
A two-hour session each month absorbs the returns, and the changes are made in the session rather than queued as follow-ups that never happen. Skip it and the network degrades into a rota of interruptions, busy and never smarter.
Cross-cutting
One System, Five Capabilities
Intent is the first fully integrated control plane for governing organizational intent and agentic orchestration. It connects purpose, authority, context, execution, evidence, judgment, and learning without forcing every team into one execution tool.
The Five
- Intent Graph: Purpose, work, ownership, and relationships in one lasting graph
- Context & Knowledge: Admissible context wired to the intent that needs it
- Governed Orchestration: Authorized human and agent capacity coordinated across tools
- Evidence & Judgment: Every result carries its proof chain and accountable decision
- Authority & Policy: Permissions, constraints, and judgment gates travel with the work
The spec and harness are critical verification mechanisms inside this control plane. They are not the platform by themselves.
Where the platform is absent, these concerns do not disappear. They are held by the Intent Architect, the human counterpart of the control plane.
Cross-cutting
The Problem Underneath
The guiding principle has not changed in twenty years. Work in small increments, sequence the highest value first, and get feedback quickly. What changed is the cost of an increment. As delivery time for a unit of work falls toward zero, the constraint moves to the slowest remaining human step: deciding what should be built, judging whether what came back is right, and supplying the domain knowledge needed for either call. An organization built around the old constraint cannot feel the benefit, because planning increments, standing teams, and stage-gate review all exist to ration scarce delivery capacity, and they hold abundant capacity back rather than release it.
The Three Questions the Model Answers
Decision rights, and how fast A Decision Owner decides inside a bounded envelope, same day, and everything else escalates on a bounded path. How do we know it is right? The spec declares what right means before the build, and the harness proves it continuously in CI. The people question The work changes shape rather than disappearing. Judgment, domain knowledge, and accountability become more valuable as production becomes cheaper. What thins out is coordination that exists only to manage handoffs.
Three Passes
Read it as three passes. The left rail follows one piece of work through its lifecycle from intake to release. The three bands in the center are the structures the work moves through: portfolio direction, Effort Teams with AI fleets, and the domain knowledge network. The right rail is the governance heartbeat that keeps everything synchronized.
The Color System
Navy to blue means direction, from the officer level (Intent Council) to the tactical level (Flow Council). Gold means execution: the Fleet Lead and the agent fleet. Green means domain judgment: the knowledge network, the Decision Owner, the spec, acceptance, and validation.
A Living Artifact
This comes out of years of direct work on organizational flow, and it is deliberately unfinished. The numbers here, release levels, ratios, and timeboxes, are calibrated starting points rather than constants. Run it, watch what happens, and feed what you learn back in. A model that cannot be corrected by the evidence it produces is an oracle. This is not one.
Operating Guidelines
Eight Guidelines
These are the concise rules for running the model. They sit between the model's mechanisms and the deeper axioms and principles beneath them.
Each guideline makes one or more axioms operational. Together they provide a practical reading of how the organization behaves day to day.
Using Them
Each guideline is a standing answer to a judgment call that would otherwise be re-litigated in every meeting. A regulated insurer and a consumer software company hold the same axioms and tune these eight differently. Adopting the model means adopting the eight as defaults, then earning local variations with evidence rather than preference.
The Enforcement Test
A guideline no mechanism enforces is a poster. Each of the eight points at the band that enforces it, which is what separates this list from the values page of an annual report.
Foundation
Six Axioms, Eighteen Principles
The axioms state what is true when AI changes the constraint profile of an organization. The principles describe how the organization must behave because those things are true.
Each principle is tied to a visible mechanism in the model. If a principle is not enforced by the operating system, it is a slogan rather than a foundation.
Using the Foundation
When a practice and an axiom collide, the practice loses. Mechanisms adapt to context and tooling changes with the market, and the axioms do not move, which makes them the test for any proposed change to the model. Name the axiom a change serves. A change that serves none of the six is decoration, and a change that fights one is a regression wearing new clothes.
Reading the Chart With Them
Read upward from an axiom to see an invariant become daily practice. Read downward from any band when something on the chart feels arbitrary, because it almost never is. The reasoning bottoms out here.