![\"A](\"/img/2026-10/01-taste.webp\")
The email arrives with a photograph and a short note. “Same seal as the pump we bought in 2008. Can you get one by tomorrow?”
The nameplate in the photograph is missing two digits. There are three versions of the pump in the catalog. Someone at the parts counter has to figure out which one the customer owns before anyone can promise a delivery date.
Imagine you run that distributor. You could use an AI agent to help the quote desk deal with emails like this more cheaply. You could also sell a next-day sourcing service to customers who will pay to get a hard-to-find part located and verified. Both jobs start with the same email. They come to the investment meeting with different evidence. The new service needs paying customers. The quote desk needs a cost it can take out of the budget.
There is a third decision waiting for both teams. A model supplier will eventually ship another version. Some instructions and scripts that helped the old model may be work the new one can do. How do you find out what you can take away?
The distributor already sells parts. The new thing is a promise that customers can buy. Send us what you know about the broken pump, and by the next business day we will give you a verified source and a lead time. A person can deliver the first version of this service with a phone, a catalog and a way to take payment.
That pilot tells you something a demonstration cannot. Will a maintenance manager actually pay $100 for the promise? It also gives the team the first version of the process. Record how many paid orders customers place and how many the desk can finish. For each request, keep the part you identified, who verified it and when the answer went out. Those records become the beginning of the data model and the first cases against which the team can test the agent.
Say the team gets 200 eligible requests in a typical month. In this example, it manually fulfills 30 paid orders at $100 each. At $60 in delivery cost per order, the service contributes $1,200 a month before shared overhead. Suppose a workflow with the model can handle 45 orders a month. It costs $40 to deliver each order, plus $200 a month to run the workflow. Getting it started costs $2,000.
Start with the 30 orders you already have. At the same $100 fee, revenue is $3,000 a month either way. Over twelve months, the lower delivery cost adds $2,800 in contribution after the launch cost. Now find 15 more orders a month from customers willing to pay for the same promise. At 45 paid orders, monthly revenue rises to $4,500 and monthly contribution to $2,500. Over those twelve months, the gain over the manual pilot rises to $13,600 after the launch cost.
You can test whether the desk has room for those extra orders before you know whether customers will place them. The sales case needs both. If buyers move over from an existing paid service, account for the sales and margin that move with them. If the objective is to attract outside capital, track funding commitments as a separate result.
Greenfield helps because you can design a small process around what people are willing to buy. You can change the intake form or narrow the promise without unwinding years of practice. You still need a way to say what good work looks like. In this example, the team asks for at least 98% correct results and a turnaround within one working day on 95% of cases. The new service can use the same old catalog, inventory and supplier records as the quote desk. How much infrastructure you inherit is a separate question from where the money comes from.
Walk over to the existing desk and follow an email from arrival to the point when a correct quote reaches the customer. A written procedure helps. So do the people who can tell you what they do when the procedure runs out. One employee knows that a certain vendor reused part numbers. Another knows that a retired brand still appears on the plates people photograph. Some of that knowledge is in a catalog. A contractor also maintains a table of verified aliases and the script that searches it.
Here the advantage of a mature process is that you have something to compare. At 1,000 quotes a month, the desk spends $5,000, including $1,000 for the alias routine and its support contract. Look at ordinary cases, bad photographs, near matches and requests that should be sent to a person. Record correctness and elapsed time all the way through review. I’ve used cost per accepted outcome for this kind of comparison because the retries and corrections belong to the job. The Cost of a Finished Job
Faster work can give people time back. That time has value, especially when someone is waiting for an answer. A field study of a customer support assistant found a 15% average increase in issues resolved per hour. To claim a reduction in operating and maintenance expense, the budget owner at our parts desk also needs to show that the team can reduce overtime, end a support contract or take another identifiable expense out of the operation. Generative AI at Work
I’d start with the part of the request that needs interpretation. A general-purpose language model can take the email and photograph, propose a part family and decide which approved lookup to try next. It can ask for the missing dimensions if the evidence runs out. A straightforward workflow can call the model once for a routine request. Some exceptions may justify letting the agent choose among several lookups.
The price comes from the transaction system. The catalog and manufacturer specifications tell you which parts are compatible. A person with the right authority decides what to do when two plausible parts remain. Put these boundaries in the tools and workflow so they apply each time the agent acts. When the model lacks an up-to-date fact, give it a lookup. When a rule is clear, implement it as a rule. A narrower machine learning model may be the right choice for a recurring classification task if you have examples and it performs better on them.
Today’s general-purpose model still struggles with some of those old vendor aliases. So keep the alias routine and give the agent access to it. Now suppose the whole desk costs $3,650 a month before the $1,000 contract. That’s $350 a month below the original desk. After a $2,000 cutover, the first year saves $2,200. The business case can stand on that result if the quality and turnaround also hold.
The table and the script do different jobs. The table holds old names that people have checked. The script looks them up. Before you switch off the script, put the verified aliases in the catalog and give someone responsibility for keeping them current. Give both workflows access to the same records. Keep compatibility, pricing and approval checks in the systems responsible for those decisions.
Use the same cases for the model you have, the new model with the script, and the new model without it. The desk requires 98% correct quotes and a turnaround of two hours or less on 95% of cases, including time spent in review. It also requires separate passes on two kinds of request. When a vendor has reused a part number, the workflow has to verify the manufacturer and the compatible part. When two plausible matches remain, it has to send the case to a person before releasing a quote. A miss on either test can block the change even at 98.9% overall. The usual pricing and approval checks still apply.
Say the new model without the script comes in at 98.9% correct, with an hour and a half for 95% of cases, and passes the required tests. That earns a trial on live requests with people still releasing the quotes. You now have an answer to whether the upgrade can do the work without the script. You still have to decide whether to buy the upgrade.
From the original quote desk, suppose the total cutover would cost $3,000. At $3,800 a month for the new workflow, ending the $1,000 support contract would save $11,400 over twelve months after accounting for the cutover. Keep paying for support and the same comparison shows a $600 loss.
If today’s model is already running, start with the $4,650 the desk spends each month. The original cutover is behind you. Suppose another $1,000 is still needed to switch. End the support contract and you save $850 a month, or $9,200 over twelve months after the switch cost. Keep the contract and the new model costs $150 more each month. Including the switch cost, keeping today’s model saves $2,800 over those twelve months.
A different desk may still need the contractor. Keep that bill in the calculation until someone can cancel it. If the trial holds and the switch pays, roll it out with a fallback and retire the script once the desk can do without it.
There is precedent for removing instructions that newer models can do without. Cursor reported cutting roughly two-thirds of its system prompt and described using A/B tests to tune the system on live traffic. Model changes can go the other direction too. OpenAI rolled back a GPT‑4o update in ChatGPT after it made the model too agreeable. I would keep the production version fixed where the provider allows it and run a new release through the same workflow tests before moving traffic. Cursor’s engineering write-up · OpenAI’s account of the rollback · Model Portability Is Not AI Portability
Open the Agent Business Case Lab and start with the distributor. In Growth, set Paid orders placed per month to 30 and leave fulfillment capacity at 45. See how much of the case comes from lowering the cost of delivery. In Operating cost, turn off the option to cancel the support contract. The delivery checks can still pass for the upgrade without the script, even when keeping today’s model costs less. Set Unsafe near-match tests to Failed to see what happens to the upgrade without the routine. Choose Start blank to enter your own figures and identify where they came from.
If you’re choosing where to begin, pull up one real request with the people who have to finish it. Follow it until a customer has an answer. Somewhere between that blurry photograph and the correct seal, you’ll find a job you can price, a rule somebody has to own, and a case worth keeping for the next time the model changes.
", "url": "https://tedt.org/The-Two-Business-Cases-for-AI-Agents/", "image": "/img/2026-11/two-business-cases-for-ai-agents.webp", "tags": ["AI agents","enterprise AI strategy","value streams","business case","operating costs","technical debt","model evaluation"], "date_published": "2026-11-09T00:00:00-08:00", "date_modified": "2026-11-09T00:00:00-08:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=mp","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/Human-Approval-Has-a-Speed-Limit/", "title": "Human Approval Has a Speed Limit", "summary": "AI can send work to people faster than they can review it. Calculate protected capacity, account for returned work, and set an explicit limit on incoming volume.", "content_text": "Human Approval Has a Speed LimitBefore you increase what your agents can produce, decide how much your people can responsibly review.Imagine a team receiving 120 requests an hour. An AI system handles the routine work and sends 20% of the requests to a person. Each human review takes five minutes.That sounds manageable. The machine handles most of the work. People look at the exceptions.Now count the minutes.Every hour produces 24 reviews. At five minutes each, those reviews require 120 minutes of human attention. Two qualified people would have to spend the entire hour reviewing just to keep pace.There is no time left for a meeting, an unusual case, a conversation with a customer, or correcting yesterday’s mistake. There is no time to help a colleague understand something the system got wrong.You kept the human in the loop. You just don’t have enough humans to handle the volume of reviews.This is the next practical question for organizations putting AI into their work: How much work can reach the review queue before the review stops being credible?Count the hours people actually haveIn How Much Work Can Your AI Safely Own?, I described review debt: faster assembly creates more work packages for experienced people to inspect. In The Cost of a Finished Job, I argued that human accountability requires enough context, time, expertise, and authority to make a real decision.The next step is to turn those requirements into a limit on incoming work.Return to our example. Over eight hours, the team receives 960 requests. The 20% needing review produces 192 cases. At five minutes each, that is 16 hours of review work.Suppose there are two reviewers. Both have eight-hour working days. But after their other responsibilities, each can protect four hours for this queue.The team has eight review hours available. Sixteen hours arrive.By the end of the first workday, eight hours remain unfinished. Under the same assumptions, another eight hours join them the next day. After ten workdays, the queue contains 80 hours of review work, equivalent to 960 average cases.These are illustrative numbers. The arithmetic is useful because it exposes a common planning mistake: counting a person as a full day of available capacity while assigning that person several other jobs.A headcount tells you how many people belong to the team. A review plan needs to say when those people can do this particular work. Review arrangement Review demand per day Protected capacity per day What the averaged model shows Two reviewers with four hours each 16 hours 8 hours Eight hours added to the queue each day. Two reviewers with eight hours each 16 hours 16 hours No spare capacity. Any starting queue remains. Three reviewers with eight hours each 16 hours 24 hours Eight hours available for existing work or variation. The eight-hour cases show the boundary in the calculation. They are not a recommendation to schedule uninterrupted reviewing for an entire working day.The queue is part of the controlRecent accounts of deployed systems make the human decision point visible.In its Nov. 2 account of building Copilot Cowork, Microsoft describes human review becoming a bottleneck as agents produced more code. The team used automated reviewers for early feedback and retained human checks for critical changes. It also reports a case in which several reviewer agents missed four blocking issues that people subsequently found. This is a first-party engineering account, not an independent comparison of review methods. It does, however, show why faster automated feedback and sufficient human judgment remain separate design questions.An AWS and U Mobile account published Nov. 4 describes a different setting. Its telco helpdesk investigates a subscriber’s problem and prepares corrective actions. A support agent reviews and confirms before changes execute on the live account. That arrangement places a person at a consequential point in the workflow. The account does not establish how much review traffic that person can absorb.The capacity question follows from both examples. What happens when requests arrive faster than qualified people can inspect them?The system might wait. Someone might work late. A team might begin approving larger batches. Reviewers might spend less time recovering context or challenging the proposed action.Those are different operating responses. Each deserves an explicit decision. A growing queue should make the limitation visible before people quietly absorb it through overtime or thinner review.If approval is one of the controls that justifies letting an agent act, then the organization needs evidence that the control can operate at the authorized volume.Give incoming work a limitThe basic calculation is small enough to keep beside the workflow:Daily review demand = requests × fraction needing review × average review minutes.Daily review capacity = qualified reviewers × protected review hours × 60.Divide demand by capacity to see the load being offered to the team. In our example, demand is 200% of capacity. That does not mean the reviewers are performing at 200% utilization. It means twice as much work is arriving as their protected time can accommodate.At 100%, the averaged model has no spare capacity. An empty queue can remain empty if every assumption holds. An existing queue cannot shrink. A longer case or an interruption has no unused time waiting for it.A team can choose to plan below that boundary. The appropriate margin depends on its work: variation in case difficulty, the cost of delay, access to specialists, and the consequences of an inadequate decision.Suppose, purely as a planning example, the team chooses to admit new work up to 80% of its protected capacity. Eight available review hours become a new-work budget of 6.4 hours, or 384 minutes.Each incoming request creates one minute of expected review work: 20% multiplied by five minutes. The corresponding intake limit is therefore 384 requests per workday.Keeping the original 960 requests would require five reviewers with four protected hours each to meet that example target. The team would then have 20 review hours, with 16 committed to new demand.The 80% figure is an assumption to test, not a standard of safety. The useful change is making the relationship explicit. When protected review capacity changes, the amount of new work the system admits should be reconsidered too.An agent platform can enforce this through a dispatch limit, a bounded queue, or a pause before starting additional work. The implementation depends on where work can safely wait. A customer request may still need to be accepted and acknowledged even when its processing must be delayed or escalated.Someone should own that decision, including what happens when a time-sensitive case arrives at a full queue.Returned work also needs attentionOur first calculation assumes each reviewed case needs one pass. Real work can have mistakes that require additional review passes. Additionally, a review might find something as complete, only to find out later that it was incomplete or incorrect, necessitating further review.Consider the arrangement with two reviewers protecting eight hours each. New demand exactly fills their 16 hours. Now suppose 25% of reviewed cases need one additional four-minute pass.The average workload becomes six minutes per reviewed case: five minutes initially, plus one minute for the additional pass averaged across all cases.Daily demand rises from 16 hours to 19.2. Capacity remains at 16. The queue gains 3.2 hours each day.This example includes exactly one additional pass. A workflow with repeated returns needs to measure those passes too. Counting only the first approval request would hide part of the job.The same care applies to the work class. Five people are not interchangeable capacity if only one can judge a particular exception. Separate the specialist queue before pooling the hours. Otherwise, the total can look comfortable while the cases that matter wait for the same person.Review time also has content. A useful review may require opening the source record, checking the relevant policy, resolving an ambiguity, and understanding what the proposed action will change. Measure that work, including corrections and follow-up. The time taken to click an approval button is a poor substitute.Know the process before you accelerate itIf this calculation and way of thinking feels strange to you, you are not yet ready to put AI into this process. You need to understand the work well enough to plan for what happens when more work arrives.That may be uncomfortable to hear, especially if someone is already asking you for an AI implementation date. You may have inherited a process whose measurements were never collected. The people doing the work may have kept it moving through experience, informal conversations, and extra hours. Give yourself and those people time to make that work visible.Start by following a request from arrival to a finished outcome. Sit with the people who handle it. Ask what they check, where they wait, what comes back, and which decisions require someone with particular experience or authority. Include the awkward cases that do not fit the procedure.Then collect the information needed to make a capacity plan: How much work arrives, over what period, and how sharply arrivals vary. Which requests need human review, why they need it, and who can perform it. How much active effort a complete review takes, including gathering context and checking evidence. How often work returns and how much additional effort each return requires. How many qualified review hours are actually protected after other responsibilities. How much work is already waiting, how old it is, and what happens when a decision is late.Use existing records where they are useful. Observe or sample the work where the records are incomplete. Include busy periods and difficult cases. Keep active effort separate from elapsed waiting time; both matter, but they answer different planning questions.Your first estimates will have gaps. Mark them, ask the people closest to the work to challenge them, and replace them with observations. Collecting this information belongs in the AI implementation plan, with time and people assigned to it.The queue should not be a surprise discovered after launch. Work through the demand, review effort, and available capacity while you can still change the plan. The people responsible for the decisions deserve that preparation before more work starts arriving.Try the Review Capacity LabThe Review Capacity Lab lets you work through these choices in your browser. Start with the article example, then change the number of reviewers or their protected hours. Load the exact-capacity example and notice that its starting queue never clears. Add re-review and watch the workload change.You can enter your own assumptions, inspect the daily table, and export the scenario and workload timeline. The staffing calculation distinguishes keeping up with new work from clearing the starting queue within the chosen window.The lab uses averaged daily totals. It does not predict actual waiting times, reviewer fatigue, decision quality, or the effect of a morning burst of difficult cases. Its case-equivalent count expresses remaining workload; it is not a count of partly approved real decisions. A result showing spare hours is a reason to investigate the workflow, not permission to increase an agent’s authority.Use actual queue records to improve the assumptions. How many requests arrived? How many needed review? How long did the complete review take? How much work returned? How old were the cases when someone finally decided them?Then compare those observations with the amount of review time the organization protected.The practical response may be to improve the evidence package so people can review it more efficiently. It may be to narrow the work admitted to the automated path, allocate more qualified review time, or improve independent checks before reconsidering which cases require human attention. Required approvals still apply. Every proposed change needs its own evidence.There is a human commitment inside this calculation. If a person is responsible for a decision, the organization owes that person a workable opportunity to understand it, challenge it, and refuse it.Before the next batch starts, decide how much work can reach the review queue. Then protect the time in which someone qualified can finish the decision.", "content_html": "Before you increase what your agents can produce, decide how much your people can responsibly review.
Imagine a team receiving 120 requests an hour. An AI system handles the routine work and sends 20% of the requests to a person. Each human review takes five minutes.
That sounds manageable. The machine handles most of the work. People look at the exceptions.
Now count the minutes.
Every hour produces 24 reviews. At five minutes each, those reviews require 120 minutes of human attention. Two qualified people would have to spend the entire hour reviewing just to keep pace.
There is no time left for a meeting, an unusual case, a conversation with a customer, or correcting yesterday’s mistake. There is no time to help a colleague understand something the system got wrong.
You kept the human in the loop. You just don’t have enough humans to handle the volume of reviews.
This is the next practical question for organizations putting AI into their work: How much work can reach the review queue before the review stops being credible?
In How Much Work Can Your AI Safely Own?, I described review debt: faster assembly creates more work packages for experienced people to inspect. In The Cost of a Finished Job, I argued that human accountability requires enough context, time, expertise, and authority to make a real decision.
The next step is to turn those requirements into a limit on incoming work.
Return to our example. Over eight hours, the team receives 960 requests. The 20% needing review produces 192 cases. At five minutes each, that is 16 hours of review work.
Suppose there are two reviewers. Both have eight-hour working days. But after their other responsibilities, each can protect four hours for this queue.
The team has eight review hours available. Sixteen hours arrive.
By the end of the first workday, eight hours remain unfinished. Under the same assumptions, another eight hours join them the next day. After ten workdays, the queue contains 80 hours of review work, equivalent to 960 average cases.
These are illustrative numbers. The arithmetic is useful because it exposes a common planning mistake: counting a person as a full day of available capacity while assigning that person several other jobs.
A headcount tells you how many people belong to the team. A review plan needs to say when those people can do this particular work.
| Review arrangement | Review demand per day | Protected capacity per day | What the averaged model shows |
|---|---|---|---|
| Two reviewers with four hours each | 16 hours | 8 hours | Eight hours added to the queue each day. |
| Two reviewers with eight hours each | 16 hours | 16 hours | No spare capacity. Any starting queue remains. |
| Three reviewers with eight hours each | 16 hours | 24 hours | Eight hours available for existing work or variation. |
The eight-hour cases show the boundary in the calculation. They are not a recommendation to schedule uninterrupted reviewing for an entire working day.
Recent accounts of deployed systems make the human decision point visible.
In its Nov. 2 account of building Copilot Cowork, Microsoft describes human review becoming a bottleneck as agents produced more code. The team used automated reviewers for early feedback and retained human checks for critical changes. It also reports a case in which several reviewer agents missed four blocking issues that people subsequently found. This is a first-party engineering account, not an independent comparison of review methods. It does, however, show why faster automated feedback and sufficient human judgment remain separate design questions.
An AWS and U Mobile account published Nov. 4 describes a different setting. Its telco helpdesk investigates a subscriber’s problem and prepares corrective actions. A support agent reviews and confirms before changes execute on the live account. That arrangement places a person at a consequential point in the workflow. The account does not establish how much review traffic that person can absorb.
The capacity question follows from both examples. What happens when requests arrive faster than qualified people can inspect them?
The system might wait. Someone might work late. A team might begin approving larger batches. Reviewers might spend less time recovering context or challenging the proposed action.
Those are different operating responses. Each deserves an explicit decision. A growing queue should make the limitation visible before people quietly absorb it through overtime or thinner review.
If approval is one of the controls that justifies letting an agent act, then the organization needs evidence that the control can operate at the authorized volume.
The basic calculation is small enough to keep beside the workflow:
Daily review demand = requests × fraction needing review × average review minutes.
Daily review capacity = qualified reviewers × protected review hours × 60.
Divide demand by capacity to see the load being offered to the team. In our example, demand is 200% of capacity. That does not mean the reviewers are performing at 200% utilization. It means twice as much work is arriving as their protected time can accommodate.
At 100%, the averaged model has no spare capacity. An empty queue can remain empty if every assumption holds. An existing queue cannot shrink. A longer case or an interruption has no unused time waiting for it.
A team can choose to plan below that boundary. The appropriate margin depends on its work: variation in case difficulty, the cost of delay, access to specialists, and the consequences of an inadequate decision.
Suppose, purely as a planning example, the team chooses to admit new work up to 80% of its protected capacity. Eight available review hours become a new-work budget of 6.4 hours, or 384 minutes.
Each incoming request creates one minute of expected review work: 20% multiplied by five minutes. The corresponding intake limit is therefore 384 requests per workday.
Keeping the original 960 requests would require five reviewers with four protected hours each to meet that example target. The team would then have 20 review hours, with 16 committed to new demand.
The 80% figure is an assumption to test, not a standard of safety. The useful change is making the relationship explicit. When protected review capacity changes, the amount of new work the system admits should be reconsidered too.
An agent platform can enforce this through a dispatch limit, a bounded queue, or a pause before starting additional work. The implementation depends on where work can safely wait. A customer request may still need to be accepted and acknowledged even when its processing must be delayed or escalated.
Someone should own that decision, including what happens when a time-sensitive case arrives at a full queue.
Our first calculation assumes each reviewed case needs one pass. Real work can have mistakes that require additional review passes. Additionally, a review might find something as complete, only to find out later that it was incomplete or incorrect, necessitating further review.
Consider the arrangement with two reviewers protecting eight hours each. New demand exactly fills their 16 hours. Now suppose 25% of reviewed cases need one additional four-minute pass.
The average workload becomes six minutes per reviewed case: five minutes initially, plus one minute for the additional pass averaged across all cases.
Daily demand rises from 16 hours to 19.2. Capacity remains at 16. The queue gains 3.2 hours each day.
This example includes exactly one additional pass. A workflow with repeated returns needs to measure those passes too. Counting only the first approval request would hide part of the job.
The same care applies to the work class. Five people are not interchangeable capacity if only one can judge a particular exception. Separate the specialist queue before pooling the hours. Otherwise, the total can look comfortable while the cases that matter wait for the same person.
Review time also has content. A useful review may require opening the source record, checking the relevant policy, resolving an ambiguity, and understanding what the proposed action will change. Measure that work, including corrections and follow-up. The time taken to click an approval button is a poor substitute.
If this calculation and way of thinking feels strange to you, you are not yet ready to put AI into this process. You need to understand the work well enough to plan for what happens when more work arrives.
That may be uncomfortable to hear, especially if someone is already asking you for an AI implementation date. You may have inherited a process whose measurements were never collected. The people doing the work may have kept it moving through experience, informal conversations, and extra hours. Give yourself and those people time to make that work visible.
Start by following a request from arrival to a finished outcome. Sit with the people who handle it. Ask what they check, where they wait, what comes back, and which decisions require someone with particular experience or authority. Include the awkward cases that do not fit the procedure.
Then collect the information needed to make a capacity plan:
Use existing records where they are useful. Observe or sample the work where the records are incomplete. Include busy periods and difficult cases. Keep active effort separate from elapsed waiting time; both matter, but they answer different planning questions.
Your first estimates will have gaps. Mark them, ask the people closest to the work to challenge them, and replace them with observations. Collecting this information belongs in the AI implementation plan, with time and people assigned to it.
The queue should not be a surprise discovered after launch. Work through the demand, review effort, and available capacity while you can still change the plan. The people responsible for the decisions deserve that preparation before more work starts arriving.
The Review Capacity Lab lets you work through these choices in your browser. Start with the article example, then change the number of reviewers or their protected hours. Load the exact-capacity example and notice that its starting queue never clears. Add re-review and watch the workload change.
You can enter your own assumptions, inspect the daily table, and export the scenario and workload timeline. The staffing calculation distinguishes keeping up with new work from clearing the starting queue within the chosen window.
The lab uses averaged daily totals. It does not predict actual waiting times, reviewer fatigue, decision quality, or the effect of a morning burst of difficult cases. Its case-equivalent count expresses remaining workload; it is not a count of partly approved real decisions. A result showing spare hours is a reason to investigate the workflow, not permission to increase an agent’s authority.
Use actual queue records to improve the assumptions. How many requests arrived? How many needed review? How long did the complete review take? How much work returned? How old were the cases when someone finally decided them?
Then compare those observations with the amount of review time the organization protected.
The practical response may be to improve the evidence package so people can review it more efficiently. It may be to narrow the work admitted to the automated path, allocate more qualified review time, or improve independent checks before reconsidering which cases require human attention. Required approvals still apply. Every proposed change needs its own evidence.
There is a human commitment inside this calculation. If a person is responsible for a decision, the organization owes that person a workable opportunity to understand it, challenge it, and refuse it.
Before the next batch starts, decide how much work can reach the review queue. Then protect the time in which someone qualified can finish the decision.
", "url": "https://tedt.org/Human-Approval-Has-a-Speed-Limit/", "image": "/img/2026-11/The-New-Bottle-Neck.webp", "tags": ["human oversight","review capacity","AI governance","agentic AI","workflow management","operating model","responsible AI","queue management","AI implementation"], "date_published": "2026-11-05T23:00:00-08:00", "date_modified": "2026-11-05T23:00:00-08:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=mp","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/Your-AI-Passed-the-Test/", "title": "Your AI Passed the Test. Did It Answer the Business Question?", "summary": "AI evaluations should test whether an assistant answers the business question, not just whether its response matches a source.", "content_text": "Your AI Passed the Test. Did It Answer the Business Question?Before a product team puts an AI assistant into production, it needs a way to determine whether the assistant can be hired to do the job. That is what evaluations, usually shortened to evals, are for. Evals are different the the tests used in traditional software development, and they are different then the performance metrics used to assess human employees. They are also not user acceptance tests.An eval is a structured test: give the AI a task, observe what it does, and compare the result with expectations established beforehand. Success might mean answering correctly, completing an action, asking a necessary question, or recognizing that the available information cannot support a conclusion.Evals are more than a successful demonstration or a score showing how quickly an assistant works. They can include familiar software tests and support user acceptance testing, the testing is not about getting the answer right every time, but to understand its behavior under different circumstances. In other words, they examine how the AI handles a range of tasks and conditions. They provide evidence for deciding where the assistant is dependablly competent to do the job following the right process, where it needs help, and what must improve before release. Traditional Concepts What this means in an AI World Traditional software tests Evals can include these, but an agent may have several acceptable answers or ways to complete a task. Checking for one exact output may miss whether it accomplished the work. User acceptance testing Evals can supply evidence for UAT. They are not synonymous with stakeholder approval, and their usefulness continues after release. An employee performance review Business requirements and outcome measures can carry over. But an eval assesses a particular combination of model, instructions, tools and data—not a person’s effort, motivation or general professional competence. A productivity dashboard Speed, cost and output volume can be measured. Those measures alone do not establish that the agent completed the right work correctly. A successful demonstration A convincing example shows that something worked on that occasion. A useful eval examines a defined collection of cases, including difficult situations and failures, often through repeated attempts. Training Running an eval measures performance. It does not, by itself, teach the model or repair the product. The results help people decide what to change. A certificate of reliability Passing provides evidence about the cases and criteria tested. It does not guarantee success on unfamiliar tasks or after the system changes. Teams collect these test cases and run them against different versions of their product. The results help them identify weaknesses that need attention, compare changes to the application or the model over time, and decide what portions of the application are ready for release. The process is repeatable, although the AI’s responses may vary between attempts. Anthropic’s guide to evaluations describes these building blocks.Consider a fictional company developing an assistant that answers questions about cloud spending. The documents show $120,000 was spent for systems used by customers and employees, $30,000 for software development, and $10,000 for testing. Together, they cover all company cloud costs for the same quarter.When the assistant is asked to provide a figure for total spending, the assistant should answer $160,000.Now change the test. Give the assistant only the $120,000 report, which explicitly excludes development and testing. It answers: “Our total cloud spending last quarter was $120,000.”That number is present in the report and approves the response.The number is correct. But is there any support for that conclusion? The company-wide claim is unsupported.A simple checker is plainly inadequate: it verifies that a value appears in a source without checking whether the source supports the complete claim. But the example exposes a broader design problem. An eval can correctly enforce its scoring rules while those rules fail to capture what the business needs.A more capable grader helps only if the evaluation gives it the right job.In Right Numbers, Wrong Questions, posted October 28, 2026, TIFIN researchers examined constructed Indian mutual-fund questions involving ambiguous figures, product variants and missing investor information.They also tested an AI judge. Providing a dictionary of field definitions helped it identify 40 of 44 mislabeled figures. Yet, without being told the intended interpretation, it accepted 42 of 52 answers that silently chose one reading of a vague question.This was their key finding. A judge assessing whether an answer addresses “the question as asked” can accept a plausible reading without requiring the assistant to disclose that reading. Better definitions improved one check; they did not establish that the answer matched the user’s unstated intention. Requiring explicit interpretations was proposed, but not tested as a remedy. These were controlled research cases, not failure rates for deployed businesses.Other research posted that day supplies related evidence. Beyond fabrication found numerical claims in AI-written research that used existing values from the wrong experiment, metric or run. DeoGen found that models performed substantially worse when policy questions lacked enough information for a conclusion. That study used generated cases from four U.S. policy texts, with extended reasoning disabled.These studies examine different failures. They do not establish how often the problem occurs across enterprises or prove that particular remedies will work in production. They give product teams specific behaviors to investigate: preserving a figure’s meaning, attributing it to the correct result, and recognizing when a necessary fact is missing.In The Map Is Not the Decision, I argued that analytical outputs need explicit assumptions and boundaries around what they can support. Evaluation makes that requirement concrete. A passing result should depend on whether the answer stays within those boundaries.For a product team, the work begins before the AI runs.Someone must assemble representative questions, the information available for each, and the behavior that the job was completed successfully. A test runner can then submit those cases to the product, capture its responses and actions, apply grading rules, and record the results. After a change, the team runs the cases again and compares performance. OpenAI’s evaluation guidance recommends this cycle of defined objectives, representative cases, measurement and continued evaluation.The grader might be ordinary software checking a calculation, a person assessing an explanation, or another AI applying written criteria. Different parts of the same task can use different graders. An assistant that updates a record should be checked against the resulting record, as well as what it says it did. These distinctions are covered in Anthropic’s evaluation guide.For the fictional cloud-cost assistant, one test result could look like this: Part of the test What it records User’s question What was total company cloud spending last quarter? Available evidence A report covering only production costs: $120,000. Required behavior Identify the limited scope; retrieve missing costs if authorized and available, or explain that the total cannot yet be established. Assistant’s answer Total company spending was $120,000. Grade Fail: a partial figure was presented as a complete total. Next action Investigate the retrieved records, instructions and grading rules before approving the change. The failure identifies behavior that needs attention. It does not, by itself, establish the cause. Perhaps the search process missed available records. Perhaps the assistant ignored the report’s exclusions. Perhaps the product never specified what to do with incomplete information.Running an eval does not repair any of those problems. It gives the team evidence with which to investigate them.This is why domain specialists belong in evaluation design. Engineers can build the machinery, while finance, operations or customer-support specialists help establish what a correct result means. If finance defines spending as payments made and procurement means purchase orders issued, the product team must resolve that difference—or specify when the assistant should present both measures.As I argued in How to Communicate in a World of AI, specifications preserve intent. Here, that intent must reach the grading rules. “Be accurate” leaves too much unstated. “Do not present production-only costs as a company-wide total” is a requirement someone can test.The grader also needs scrutiny. Give it a well-cited answer from the wrong quarter. Give it a correct answer phrased differently from the reference answer. Check whether it rejects the misleading response and accepts the valid one.Then connect those results to a decision.Suppose the team is considering a faster, cheaper version of the cloud-cost assistant. Its overall evaluation score improves, but it now presents production-only costs as total company spending.Before testing, the product owner and finance specialist agreed that this failure would block release. The team therefore holds the update, investigates the defect, makes a change, and reruns the relevant tests. It also checks that the assistant still answers directly when complete records are available.This is a hypothetical release decision, but it illustrates the practical value of evals. An aggregate improvement does not settle whether a change meets the product’s requirements. The team needs to know which behaviors improved, which deteriorated, and whether any failure violates a requirement it considers essential.Those requirements should reflect the consequences of the work. A confusing sentence and an unsupported financial total need not carry the same weight.There is also a cost to excessive caution. The financial-query study found that one intervention reduced wrong answers while introducing unnecessary clarification. Stronger models handled some missing-information tasks successfully. More questions were not a universal improvement. Right Numbers, Wrong Questions.For our cloud-cost assistant, the team should therefore test both conditions: incomplete records should prevent an unsupported total; complete records should produce a direct answer. If an approved definition of spending already exists, the assistant should use it rather than repeatedly asking the user to define the term.The team can track consequential errors, unnecessary questions, unresolved requests and time to completion separately. That makes it easier to see whether a proposed improvement helps users finish their work or merely transfers more effort to them.A passing evaluation remains bounded evidence. It shows how the system performed on selected cases under particular grading rules. It does not guarantee every future response. A live check of an individual answer is a separate control, whose effectiveness can itself be evaluated.These tests also need to continue as the product changes. A different model, revised instruction, new search process or renamed data field can alter behavior. As Dev, Test, and Prod Still Matter: What Gets Deployed Has Changed explains, assurance needs to follow the system being deployed. Try it: follow an answer from evidence to release The Founding Documents AI Evaluation Lab puts these ideas into practice with public U.S. documents. Its first exercise confuses amendments proposed in 1789 with those ratified in 1791. Follow the retrieved passage, compare the graders, and decide whether the answer meets the requirement for release. Interactive lab: follow the evidence and test the release decision Six short lessons · about 20 minutes · no API key needed for replay Start in Replay with Candidate selected. This version passes more cases overall but fails one requirement that blocks release. Open the action trace and follow the citation to the passage the agent retrieved. Compare the weak checker with the task-specific grades. Notice which question each one answers. Choose Decide what can ship, then switch the agent version to Revised. Compare the results before changing the release policy. Replay uses authored teaching responses scored with Microsoft Agent Framework. Optional live runs use your own model connection. The lab also includes Python and React downloads for your own experiments. On a small screen, use the link below to give the lab's evidence and controls more room. Open the lab in a new tab Select Interactive lab above again to collapse this exercise and return to the article. The interactive lab requires JavaScript. You can also read the instructor guide. A useful starting point is one answer the product currently passes. Change the scope of its evidence without changing the number. Remove a fact required for its conclusion. Then restore complete information.Check whether the product limits its claims when the evidence is incomplete—and answers directly when the evidence is sufficient.", "content_html": "Your AI Passed the Test. Did It Answer the Business Question?
Before a product team puts an AI assistant into production, it needs a way to determine whether the assistant can be hired to do the job. That is what evaluations, usually shortened to evals, are for. Evals are different the the tests used in traditional software development, and they are different then the performance metrics used to assess human employees. They are also not user acceptance tests.
An eval is a structured test: give the AI a task, observe what it does, and compare the result with expectations established beforehand. Success might mean answering correctly, completing an action, asking a necessary question, or recognizing that the available information cannot support a conclusion.
Evals are more than a successful demonstration or a score showing how quickly an assistant works. They can include familiar software tests and support user acceptance testing, the testing is not about getting the answer right every time, but to understand its behavior under different circumstances. In other words, they examine how the AI handles a range of tasks and conditions. They provide evidence for deciding where the assistant is dependablly competent to do the job following the right process, where it needs help, and what must improve before release.
| Traditional Concepts | What this means in an AI World |
|---|---|
| Traditional software tests | Evals can include these, but an agent may have several acceptable answers or ways to complete a task. Checking for one exact output may miss whether it accomplished the work. |
| User acceptance testing | Evals can supply evidence for UAT. They are not synonymous with stakeholder approval, and their usefulness continues after release. |
| An employee performance review | Business requirements and outcome measures can carry over. But an eval assesses a particular combination of model, instructions, tools and data—not a person’s effort, motivation or general professional competence. |
| A productivity dashboard | Speed, cost and output volume can be measured. Those measures alone do not establish that the agent completed the right work correctly. |
| A successful demonstration | A convincing example shows that something worked on that occasion. A useful eval examines a defined collection of cases, including difficult situations and failures, often through repeated attempts. |
| Training | Running an eval measures performance. It does not, by itself, teach the model or repair the product. The results help people decide what to change. |
| A certificate of reliability | Passing provides evidence about the cases and criteria tested. It does not guarantee success on unfamiliar tasks or after the system changes. |
Teams collect these test cases and run them against different versions of their product. The results help them identify weaknesses that need attention, compare changes to the application or the model over time, and decide what portions of the application are ready for release. The process is repeatable, although the AI’s responses may vary between attempts. Anthropic’s guide to evaluations describes these building blocks.
Consider a fictional company developing an assistant that answers questions about cloud spending. The documents show $120,000 was spent for systems used by customers and employees, $30,000 for software development, and $10,000 for testing. Together, they cover all company cloud costs for the same quarter.
When the assistant is asked to provide a figure for total spending, the assistant should answer $160,000.
Now change the test. Give the assistant only the $120,000 report, which explicitly excludes development and testing. It answers:
“Our total cloud spending last quarter was $120,000.”
That number is present in the report and approves the response.
The number is correct. But is there any support for that conclusion? The company-wide claim is unsupported.
A simple checker is plainly inadequate: it verifies that a value appears in a source without checking whether the source supports the complete claim. But the example exposes a broader design problem. An eval can correctly enforce its scoring rules while those rules fail to capture what the business needs.
A more capable grader helps only if the evaluation gives it the right job.
In Right Numbers, Wrong Questions, posted October 28, 2026, TIFIN researchers examined constructed Indian mutual-fund questions involving ambiguous figures, product variants and missing investor information.
They also tested an AI judge. Providing a dictionary of field definitions helped it identify 40 of 44 mislabeled figures. Yet, without being told the intended interpretation, it accepted 42 of 52 answers that silently chose one reading of a vague question.
This was their key finding. A judge assessing whether an answer addresses “the question as asked” can accept a plausible reading without requiring the assistant to disclose that reading. Better definitions improved one check; they did not establish that the answer matched the user’s unstated intention. Requiring explicit interpretations was proposed, but not tested as a remedy. These were controlled research cases, not failure rates for deployed businesses.
Other research posted that day supplies related evidence. Beyond fabrication found numerical claims in AI-written research that used existing values from the wrong experiment, metric or run. DeoGen found that models performed substantially worse when policy questions lacked enough information for a conclusion. That study used generated cases from four U.S. policy texts, with extended reasoning disabled.
These studies examine different failures. They do not establish how often the problem occurs across enterprises or prove that particular remedies will work in production. They give product teams specific behaviors to investigate: preserving a figure’s meaning, attributing it to the correct result, and recognizing when a necessary fact is missing.
In The Map Is Not the Decision, I argued that analytical outputs need explicit assumptions and boundaries around what they can support. Evaluation makes that requirement concrete. A passing result should depend on whether the answer stays within those boundaries.
For a product team, the work begins before the AI runs.
Someone must assemble representative questions, the information available for each, and the behavior that the job was completed successfully. A test runner can then submit those cases to the product, capture its responses and actions, apply grading rules, and record the results. After a change, the team runs the cases again and compares performance. OpenAI’s evaluation guidance recommends this cycle of defined objectives, representative cases, measurement and continued evaluation.
The grader might be ordinary software checking a calculation, a person assessing an explanation, or another AI applying written criteria. Different parts of the same task can use different graders. An assistant that updates a record should be checked against the resulting record, as well as what it says it did. These distinctions are covered in Anthropic’s evaluation guide.
For the fictional cloud-cost assistant, one test result could look like this:
| Part of the test | What it records |
|---|---|
| User’s question | What was total company cloud spending last quarter? |
| Available evidence | A report covering only production costs: $120,000. |
| Required behavior | Identify the limited scope; retrieve missing costs if authorized and available, or explain that the total cannot yet be established. |
| Assistant’s answer | Total company spending was $120,000. |
| Grade | Fail: a partial figure was presented as a complete total. |
| Next action | Investigate the retrieved records, instructions and grading rules before approving the change. |
The failure identifies behavior that needs attention. It does not, by itself, establish the cause. Perhaps the search process missed available records. Perhaps the assistant ignored the report’s exclusions. Perhaps the product never specified what to do with incomplete information.
Running an eval does not repair any of those problems. It gives the team evidence with which to investigate them.
This is why domain specialists belong in evaluation design. Engineers can build the machinery, while finance, operations or customer-support specialists help establish what a correct result means. If finance defines spending as payments made and procurement means purchase orders issued, the product team must resolve that difference—or specify when the assistant should present both measures.
As I argued in How to Communicate in a World of AI, specifications preserve intent. Here, that intent must reach the grading rules. “Be accurate” leaves too much unstated. “Do not present production-only costs as a company-wide total” is a requirement someone can test.
The grader also needs scrutiny. Give it a well-cited answer from the wrong quarter. Give it a correct answer phrased differently from the reference answer. Check whether it rejects the misleading response and accepts the valid one.
Then connect those results to a decision.
Suppose the team is considering a faster, cheaper version of the cloud-cost assistant. Its overall evaluation score improves, but it now presents production-only costs as total company spending.
Before testing, the product owner and finance specialist agreed that this failure would block release. The team therefore holds the update, investigates the defect, makes a change, and reruns the relevant tests. It also checks that the assistant still answers directly when complete records are available.
This is a hypothetical release decision, but it illustrates the practical value of evals. An aggregate improvement does not settle whether a change meets the product’s requirements. The team needs to know which behaviors improved, which deteriorated, and whether any failure violates a requirement it considers essential.
Those requirements should reflect the consequences of the work. A confusing sentence and an unsupported financial total need not carry the same weight.
There is also a cost to excessive caution. The financial-query study found that one intervention reduced wrong answers while introducing unnecessary clarification. Stronger models handled some missing-information tasks successfully. More questions were not a universal improvement. Right Numbers, Wrong Questions.
For our cloud-cost assistant, the team should therefore test both conditions: incomplete records should prevent an unsupported total; complete records should produce a direct answer. If an approved definition of spending already exists, the assistant should use it rather than repeatedly asking the user to define the term.
The team can track consequential errors, unnecessary questions, unresolved requests and time to completion separately. That makes it easier to see whether a proposed improvement helps users finish their work or merely transfers more effort to them.
A passing evaluation remains bounded evidence. It shows how the system performed on selected cases under particular grading rules. It does not guarantee every future response. A live check of an individual answer is a separate control, whose effectiveness can itself be evaluated.
These tests also need to continue as the product changes. A different model, revised instruction, new search process or renamed data field can alter behavior. As Dev, Test, and Prod Still Matter: What Gets Deployed Has Changed explains, assurance needs to follow the system being deployed.
The Founding Documents AI Evaluation Lab puts these ideas into practice with public U.S. documents. Its first exercise confuses amendments proposed in 1789 with those ratified in 1791. Follow the retrieved passage, compare the graders, and decide whether the answer meets the requirement for release.
Start in Replay with Candidate selected. This version passes more cases overall but fails one requirement that blocks release.
Replay uses authored teaching responses scored with Microsoft Agent Framework. Optional live runs use your own model connection. The lab also includes Python and React downloads for your own experiments.
On a small screen, use the link below to give the lab's evidence and controls more room.
Select Interactive lab above again to collapse this exercise and return to the article.
A useful starting point is one answer the product currently passes. Change the scope of its evidence without changing the number. Remove a fact required for its conclusion. Then restore complete information.
Check whether the product limits its claims when the evidence is incomplete—and answers directly when the evidence is sufficient.
", "url": "https://tedt.org/Your-AI-Passed-the-Test/", "image": "/img/2026-11/Your-AI-Passed-the-Test-Hero.webp", "tags": ["AI evaluations","evals","AI agents","model evaluation","software testing","AI governance","release management","business requirements","reliability"], "date_published": "2026-11-01T09:00:00-08:00", "date_modified": "2026-11-02T13:20:01-08:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/Reprint-Two-Views-of-Programming/", "title": "REPRINT: Two views of programming", "summary": "Dijkstra contrasts two views of programming and examines how tools, artificial intelligence, and management expectations shape the programmer's work and responsibility.", "content_text": "Source transcriptionArchive transcription by Jorge A. Pérez Parra; revised March 25, 2005.by Edsger W. DijkstraIn the world around us we encounter two radically different views ofprogramming: View A: Programming in essence is very easy. View B: Programming is intrinsically very difficult.One can dismiss this discrepancy by concluding that, apparently, in the twoviews the same word “programming” is used in two quite different meanings, andthen return to the order of the day. Whether view A or view B is thepredominant one, however, has a deep influence, not only on the personnelpolicy of computer using organizations and on the curriculum policy of oureducational institutes, but even on the direction of development and researchin computing science itself. It seems, therefore, worthwhile to explore thenature of the difference between the two meanings and to identify, ifpossible, the underlying assumptions that would make each of them appropriate.To do so is the purpose of this paper.In this exploration I have what could be regarded as a handicap: in thecontroversy I am not neutral at all. I am a strong supporter of view B andregard view A as the underlying cause of many mistakes. On the other hand Idon’t think that having an opinion disqualifies me as an author, certainly ifI warn my readers in advance and do not feign a fake neutrality. As ouranalysis proceeds we shall discover how these different views of programming(which is a human activity!) are related to different types of Man. This, allby itself, is already a valuable insight, as it explains the nearly religiousfervour with which the battle between the defenders of the opposing views—creeds?— is sometimes fought.The early history of automatic computing makes view A only too understandable.Before we had computers, programming was no problem at all. Then came thefirst machines: compared with the machines we have now they were mere toys,and, compared with what we try to do now, they were used for“micro-applications” only. If at that stage programming was a problem, it wasonly a mild one. Add to this the sources of difficulties that at that timeabsorbed —or should we say in retrospect: usurped?— the major part of ourattention: arithmetic units were slow with respect to what we wanted to do: that shoepinched nearly always, and in the name of program efficiency all possiblecoding tricks were permitted (and very few were not applied) design and construction of arithmetic units were such a novel and,therefore, difficult task that if a next anomaly in the instruction codecould save a number of flip-flops, the flip-flops were usually saved —also,of course, because we had so little programming experience that we couldnot recognize “anomalies in the instruction code” too well—; as a resultthere was, besides pressure to apply coding tricks, also a greatopportunity for doing so stores were always too small, a pinching shoe that, together with thegeneral unreliability of the first hardware, prohibited more sophisticatedways of machine usage. In that time programming presented itself primarily as battle against themachine’s limitations, a battle that was to be won by a cunning, be it notvery systematic, exploitation of each machine’s specific properties: it wasthe heyday of the virtuoso coder.In the next to ten to fifteen years processing units became a thousand timesfaster, stores became a thousand times larger, and high-level programminglanguages came into general use. And it was during that period, when on theone hand programming was still firmly associated with the pinching shoe, whileon the other hand the shoe was felt to pinch less and less, that it wasexpected that with another five years of technical progress the problems ofprogramming would have disappeared. It was during that period that view A wasborn. It was at the end of that period that, inspired by view A, COBOL wasdesigned with the avowed intention that it should make programming byprofessional programmers superfluous by allowing the “user” —was it at thattime that the term “user” gained currency?— to write down what he wanted in“plain English” that every one could read and understand.We all know, that that splendid dream did not come true. The next five yearsgave us, instead of the disappearance of all programming problems, thesoftware crisis, and COBOL, instead of doing away with professionalprogrammers, became the major programming vehicle for ever growing numbers ofthem; and another ten years later we still have machines with which flaws inthe basic software cause on the average one hour down-time for every fifteenhours of production. There are, apparently, still serious programming problems….The amazing thing is that, in spite of the overwhelming evidence to thecontrary, view A survived. In explaining that amazing thing fact some pointwith a somewhat accusing finger to large organizations, either to computerusing ones that, having atttacted a large labour force based in view A,thereby have lost the freedom to part from it, or to computer manufacturersand educational institutes that promote a widely-held view A, that they aresupposed to suppose essential for their market. Even if that finger is notraised without some justification, I just cannot accept it as a fullexplanation of view A’s survival, and must assume that view A satisfies somedeeper, psychological needs.How emerged view B? There were people who felt that the advent of faster andbigger machines would replace the pinching shoe at most by a fitting shoe, andthat, therefore, the economics of program execution would remain a seriousconcern of the programmer, a concern that would even become more important assize of machines and applications would grow, and, with more complexinstallations, would pose more difficult problems. Also it was observed thatswitching from machine code to a high-level programming language did notguarantee all the benefits that were hoped for. In particular, programmersstill produced, as willingly as before, large chunks of ununderstandable code,the only difference being that now they did it on a more grandiose scale, andthat high-level bugs had replaced low-level ones. They also realized that theadvent of high-level programming languages had not reduced the essential needfor accuracy: redundancy in high-level programming languages only reduces theill effects of some inaccuracies. And thus view B was born. (View B is NOT thereaction to the software crisis that surfaced in 1968, for it is many yearsolder. View B had, in fact, predicted that crisis, but even that confirmationhas not killed view A.)After this interlude about the emerging of view B, we return to our question,how and why, face to face with the undeniable software problems, view A, viz.that programming is in essence very easy, survives. The answers is: by faith,not faith in better programmers, but faith in better programming languages or(conversational?) programming services, and faith in better managementtechniques.I happen to be of the considered opinion that programming is one of the moredifficult branches of applied mathematics, because it is also one of the moredifficult branches of engineering, and vice versa. When I tried to explain toone of my mathematical colleagues why I held that view, he bluntly refused tolisten to my arguments and, instead, blamed me and my fellow computingscientists for not yet having designed the programming language that wouldmake programming as easy as it should be! Should I have asked him, whymathematicians have not developed a notation that would enable everyone, nomatter how ill-equipped otherwise, to do mathematics?After more probing one discovers that the proponents of view A do not deny thepotential complexity of programs, nor the problem of composing them, butbelieve that life will become easy for the programmer because all the moredifficult parts of the task will eventually taken over by the machine. Theypoint to the advent of high-level programming languages that made programmingalready so much easier than in the old machine code days, and recklesslyextrapolate, that in the future programming will become trivial. But is thisextrapolation justified? I have programmed extensively, both in machine codesand high-level programming languages, and the latter are undoubtedly moreconvenient because all sorts of otherwise irrelevant decisions with manyclerical consequences —such as details of storage layout— need not be takenexplicitly because one accepts the outcome of the compiler’s storageallocation algorithm. The transition to a high level freed us from a number oftrivia. In doing so, it has made programming an activity with a smallercomponent of drudgery, and therefore with a larger component of invention:precisely those parts of the job with one used to fill the day when feelingless bright, are the ones that have disappeared! The conclusion that theadvent of high-level programming languages has created the need forprogrammers of higher intellectual caliber has been fully confirmed by myobservations in Western Europe (where I could follow the development at closequarters) where in the late sixties many large computer using organizationshad problems in finding appropriate employment for the programmers they hadattracted in the fifties, because their profession had outgrown theirintellectual capacities.But neither this observation, nor pointing out COBOL’s failure to do away withprofessional programmers, makes any impression upon the faithful. They willexplain that the traditional high-level programming languages were failuresbecause they were still “procedural”, and that COBOL’s failure is evidentbecause, for lack of interaction, it is not really plain English, but thatwithin five or five or ten years further progress in Artificial Intelligence(AI for the intimi) will enable us to build “context dependent”,“knowledge-based”,”automated systems for reasoning and understanding” suchthat the “user needs only talk to them”.I may be an incurable sceptic, but I find it very hard to believe such claimsto be justified. They are specific instances of the expectation that we shallwitness — I quote from a letter I recently received— “, in general, theassumption by the computer of progressively higher levels of what now isconsidered human skill, knowledge and intelligence.” It is not my intention ofto repeat parts of heated discussions we have had about the significance ofArtificial Intelligence (see, for instance, 1), nor is there any need to doso.Firstly, looking backwards, one conclusion is certain: confusing AI’s hopesfor the future with tomorrow’s reality would be folly, and it would be an actof utter irresponsibility not to prepare ourselves for the case that thedreams of AI will remain dreams as long as we live. Or, to put it in otherwords, in view of the severity of today’s programming problems, generalcautiousness forces us not to discard view B.Secondly, if his creations are going to be relied upon, it will be theprogrammer’s primary task to design his artifacts so understandable, that hecan take the responsibility for them, and, regardless of the answer to thequestion how much of his current activity may ultimately be delegated tomachines, we should always remember that neither “understanding” nor “beingresponsible” can properly be classified as activities: they are more like“states of mind” and are intrinsically incapable of being delegated.I think it unwise, particularly for a computing scientist, to underestimatethe influence of that school of psychologist that, because they found thehuman mind too difficult and elusive an object for their study, turned to thestudy of rats instead, and even restrict that study —as I saw expressedrecently— “to the most mechanical forms of behavior —often so mechanical thateven rats have no chance to show their higher faculties—”. By presenting theircrude, mechanical models as a valid approximation for the human mind, theyhave blurred the distinction between man and machine dangerously, and weobserve the two complementary phenomena: an anthropomorphic view of machinesand a mechanical view of people.This confusion is by no means confined to the high priests of AI. Thepreponderance of anthropomorphic terminology in computing science in general—”memory”, “interpreter”,”programming language”, “handshaking”,“conversation”, to mention but a few— is a warning not to be ignored. I wouldnot know how to think and talk without metaphors; I also know that eachmetaphor carries with it the danger of false connotations. In the case of theanthropomorphic terminology in computer science we have since long reached thestage that the dangers of confusion far outweigh the benefits of the analogy.Also the mechanical view of people seems among computing scientist (and theirmanagers) more widely spread than I consider healthy. For I suspect that it isthis mechanical view that restricts the activity of programmers to themechanical activity of writing code, and then measures “programmerproductivity” by the number of lines of code produced. (When a very well-knownand widely respected computer scientist recently used that measure forprogrammer productivity in a lecture, the suggestion came from the audiencethat, instead of talking about “the lines of code produced” we should talkabout “the lines of code used” and that, therefore, the speaker was bookingthem on the wrong side of the ledger. The speaker answered that he stuck tohis productivity measure, because he did not know of any alternatives thatallowed proper quantification!) This can no longer be classified as a harmlessmistake, for the adoption of that nonsensical “productivity measure” forgrading programmers is guaranteed to promote the writing of insipid code.The influence of psychology has been brought into the picture because itexplains the tenacity with which so many people cling to view A.It is not so much the computer manufacturers, that want to do as if they sellan easy product; it is not so much the managers of software projects, thatwould like to view the programming activity as a simple and predictable one;it is not so much our educational institutes, that would like to train theirstudents with predictable success.It is the comfortable illusion of Man as elaborate automata that, like a drug,seems to have freed its victims from the burden of responsibility. Acceptingprogramming as a hard intellectual challenge would place the full weight ofthat burden back upon their shoulders.Plataanstraat 5NL–4565 NUENENThe Netherlandsprof.dr.Edsger W.DijkstraBurroughs Research Fellow Flowers, B.H. “Artificial Intelligence: a paper symposium” April 1973,Science Research Council, State House, High Holborn, London WC1R 4TA. ↩ ", "content_html": "Archive transcription by Jorge A. Pérez Parra; revised March 25, 2005.
by Edsger W. Dijkstra
In the world around us we encounter two radically different views ofprogramming:
One can dismiss this discrepancy by concluding that, apparently, in the twoviews the same word “programming” is used in two quite different meanings, andthen return to the order of the day. Whether view A or view B is thepredominant one, however, has a deep influence, not only on the personnelpolicy of computer using organizations and on the curriculum policy of oureducational institutes, but even on the direction of development and researchin computing science itself. It seems, therefore, worthwhile to explore thenature of the difference between the two meanings and to identify, ifpossible, the underlying assumptions that would make each of them appropriate.To do so is the purpose of this paper.
In this exploration I have what could be regarded as a handicap: in thecontroversy I am not neutral at all. I am a strong supporter of view B andregard view A as the underlying cause of many mistakes. On the other hand Idon’t think that having an opinion disqualifies me as an author, certainly ifI warn my readers in advance and do not feign a fake neutrality. As ouranalysis proceeds we shall discover how these different views of programming(which is a human activity!) are related to different types of Man. This, allby itself, is already a valuable insight, as it explains the nearly religiousfervour with which the battle between the defenders of the opposing views—creeds?— is sometimes fought.
The early history of automatic computing makes view A only too understandable.Before we had computers, programming was no problem at all. Then came thefirst machines: compared with the machines we have now they were mere toys,and, compared with what we try to do now, they were used for“micro-applications” only. If at that stage programming was a problem, it wasonly a mild one. Add to this the sources of difficulties that at that timeabsorbed —or should we say in retrospect: usurped?— the major part of ourattention:
arithmetic units were slow with respect to what we wanted to do: that shoepinched nearly always, and in the name of program efficiency all possiblecoding tricks were permitted (and very few were not applied)
design and construction of arithmetic units were such a novel and,therefore, difficult task that if a next anomaly in the instruction codecould save a number of flip-flops, the flip-flops were usually saved —also,of course, because we had so little programming experience that we couldnot recognize “anomalies in the instruction code” too well—; as a resultthere was, besides pressure to apply coding tricks, also a greatopportunity for doing so
stores were always too small, a pinching shoe that, together with thegeneral unreliability of the first hardware, prohibited more sophisticatedways of machine usage.
In that time programming presented itself primarily as battle against themachine’s limitations, a battle that was to be won by a cunning, be it notvery systematic, exploitation of each machine’s specific properties: it wasthe heyday of the virtuoso coder.
In the next to ten to fifteen years processing units became a thousand timesfaster, stores became a thousand times larger, and high-level programminglanguages came into general use. And it was during that period, when on theone hand programming was still firmly associated with the pinching shoe, whileon the other hand the shoe was felt to pinch less and less, that it wasexpected that with another five years of technical progress the problems ofprogramming would have disappeared. It was during that period that view A wasborn. It was at the end of that period that, inspired by view A, COBOL wasdesigned with the avowed intention that it should make programming byprofessional programmers superfluous by allowing the “user” —was it at thattime that the term “user” gained currency?— to write down what he wanted in“plain English” that every one could read and understand.
We all know, that that splendid dream did not come true. The next five yearsgave us, instead of the disappearance of all programming problems, thesoftware crisis, and COBOL, instead of doing away with professionalprogrammers, became the major programming vehicle for ever growing numbers ofthem; and another ten years later we still have machines with which flaws inthe basic software cause on the average one hour down-time for every fifteenhours of production. There are, apparently, still serious programming problems….
The amazing thing is that, in spite of the overwhelming evidence to thecontrary, view A survived. In explaining that amazing thing fact some pointwith a somewhat accusing finger to large organizations, either to computerusing ones that, having atttacted a large labour force based in view A,thereby have lost the freedom to part from it, or to computer manufacturersand educational institutes that promote a widely-held view A, that they aresupposed to suppose essential for their market. Even if that finger is notraised without some justification, I just cannot accept it as a fullexplanation of view A’s survival, and must assume that view A satisfies somedeeper, psychological needs.
How emerged view B? There were people who felt that the advent of faster andbigger machines would replace the pinching shoe at most by a fitting shoe, andthat, therefore, the economics of program execution would remain a seriousconcern of the programmer, a concern that would even become more important assize of machines and applications would grow, and, with more complexinstallations, would pose more difficult problems. Also it was observed thatswitching from machine code to a high-level programming language did notguarantee all the benefits that were hoped for. In particular, programmersstill produced, as willingly as before, large chunks of ununderstandable code,the only difference being that now they did it on a more grandiose scale, andthat high-level bugs had replaced low-level ones. They also realized that theadvent of high-level programming languages had not reduced the essential needfor accuracy: redundancy in high-level programming languages only reduces theill effects of some inaccuracies. And thus view B was born. (View B is NOT thereaction to the software crisis that surfaced in 1968, for it is many yearsolder. View B had, in fact, predicted that crisis, but even that confirmationhas not killed view A.)
After this interlude about the emerging of view B, we return to our question,how and why, face to face with the undeniable software problems, view A, viz.that programming is in essence very easy, survives. The answers is: by faith,not faith in better programmers, but faith in better programming languages or(conversational?) programming services, and faith in better managementtechniques.
I happen to be of the considered opinion that programming is one of the moredifficult branches of applied mathematics, because it is also one of the moredifficult branches of engineering, and vice versa. When I tried to explain toone of my mathematical colleagues why I held that view, he bluntly refused tolisten to my arguments and, instead, blamed me and my fellow computingscientists for not yet having designed the programming language that wouldmake programming as easy as it should be! Should I have asked him, whymathematicians have not developed a notation that would enable everyone, nomatter how ill-equipped otherwise, to do mathematics?
After more probing one discovers that the proponents of view A do not deny thepotential complexity of programs, nor the problem of composing them, butbelieve that life will become easy for the programmer because all the moredifficult parts of the task will eventually taken over by the machine. Theypoint to the advent of high-level programming languages that made programmingalready so much easier than in the old machine code days, and recklesslyextrapolate, that in the future programming will become trivial. But is thisextrapolation justified? I have programmed extensively, both in machine codesand high-level programming languages, and the latter are undoubtedly moreconvenient because all sorts of otherwise irrelevant decisions with manyclerical consequences —such as details of storage layout— need not be takenexplicitly because one accepts the outcome of the compiler’s storageallocation algorithm. The transition to a high level freed us from a number oftrivia. In doing so, it has made programming an activity with a smallercomponent of drudgery, and therefore with a larger component of invention:precisely those parts of the job with one used to fill the day when feelingless bright, are the ones that have disappeared! The conclusion that theadvent of high-level programming languages has created the need forprogrammers of higher intellectual caliber has been fully confirmed by myobservations in Western Europe (where I could follow the development at closequarters) where in the late sixties many large computer using organizationshad problems in finding appropriate employment for the programmers they hadattracted in the fifties, because their profession had outgrown theirintellectual capacities.
But neither this observation, nor pointing out COBOL’s failure to do away withprofessional programmers, makes any impression upon the faithful. They willexplain that the traditional high-level programming languages were failuresbecause they were still “procedural”, and that COBOL’s failure is evidentbecause, for lack of interaction, it is not really plain English, but thatwithin five or five or ten years further progress in Artificial Intelligence(AI for the intimi) will enable us to build “context dependent”,“knowledge-based”,”automated systems for reasoning and understanding” suchthat the “user needs only talk to them”.
I may be an incurable sceptic, but I find it very hard to believe such claimsto be justified. They are specific instances of the expectation that we shallwitness — I quote from a letter I recently received— “, in general, theassumption by the computer of progressively higher levels of what now isconsidered human skill, knowledge and intelligence.” It is not my intention ofto repeat parts of heated discussions we have had about the significance ofArtificial Intelligence (see, for instance, 1), nor is there any need to doso.
Firstly, looking backwards, one conclusion is certain: confusing AI’s hopesfor the future with tomorrow’s reality would be folly, and it would be an actof utter irresponsibility not to prepare ourselves for the case that thedreams of AI will remain dreams as long as we live. Or, to put it in otherwords, in view of the severity of today’s programming problems, generalcautiousness forces us not to discard view B.
Secondly, if his creations are going to be relied upon, it will be theprogrammer’s primary task to design his artifacts so understandable, that hecan take the responsibility for them, and, regardless of the answer to thequestion how much of his current activity may ultimately be delegated tomachines, we should always remember that neither “understanding” nor “beingresponsible” can properly be classified as activities: they are more like“states of mind” and are intrinsically incapable of being delegated.
I think it unwise, particularly for a computing scientist, to underestimatethe influence of that school of psychologist that, because they found thehuman mind too difficult and elusive an object for their study, turned to thestudy of rats instead, and even restrict that study —as I saw expressedrecently— “to the most mechanical forms of behavior —often so mechanical thateven rats have no chance to show their higher faculties—”. By presenting theircrude, mechanical models as a valid approximation for the human mind, theyhave blurred the distinction between man and machine dangerously, and weobserve the two complementary phenomena: an anthropomorphic view of machinesand a mechanical view of people.
This confusion is by no means confined to the high priests of AI. Thepreponderance of anthropomorphic terminology in computing science in general—”memory”, “interpreter”,”programming language”, “handshaking”,“conversation”, to mention but a few— is a warning not to be ignored. I wouldnot know how to think and talk without metaphors; I also know that eachmetaphor carries with it the danger of false connotations. In the case of theanthropomorphic terminology in computer science we have since long reached thestage that the dangers of confusion far outweigh the benefits of the analogy.
Also the mechanical view of people seems among computing scientist (and theirmanagers) more widely spread than I consider healthy. For I suspect that it isthis mechanical view that restricts the activity of programmers to themechanical activity of writing code, and then measures “programmerproductivity” by the number of lines of code produced. (When a very well-knownand widely respected computer scientist recently used that measure forprogrammer productivity in a lecture, the suggestion came from the audiencethat, instead of talking about “the lines of code produced” we should talkabout “the lines of code used” and that, therefore, the speaker was bookingthem on the wrong side of the ledger. The speaker answered that he stuck tohis productivity measure, because he did not know of any alternatives thatallowed proper quantification!) This can no longer be classified as a harmlessmistake, for the adoption of that nonsensical “productivity measure” forgrading programmers is guaranteed to promote the writing of insipid code.
The influence of psychology has been brought into the picture because itexplains the tenacity with which so many people cling to view A.
It is not so much the computer manufacturers, that want to do as if they sellan easy product; it is not so much the managers of software projects, thatwould like to view the programming activity as a simple and predictable one;it is not so much our educational institutes, that would like to train theirstudents with predictable success.
It is the comfortable illusion of Man as elaborate automata that, like a drug,seems to have freed its victims from the burden of responsibility. Acceptingprogramming as a hard intellectual challenge would place the full weight ofthat burden back upon their shoulders.
Plataanstraat 5
NL–4565 NUENEN
The Netherlands
prof.dr.Edsger W.Dijkstra
Burroughs Research Fellow
Flowers, B.H. “Artificial Intelligence: a paper symposium” April 1973,Science Research Council, State House, High Holborn, London WC1R 4TA. ↩
There is no single development, in either technology or managementtechnique, which by itself promises even one order-of-magnitude improvementwithin a decade in productivity, in reliability, in simplicity.
Frederick P. Brooks, Jr. - University of North Carolina at Chapel Hill 1
All software construction involves essential tasks, the fashioning of thecomplex conceptual structures that compose the abstract software entity, andaccidental tasks, the representation of these abstract entities in programminglanguages and the mapping of these onto machine languages within space andspeed constraints. Most of the big past gains in software productivity havecome from removing artificial barriers that have made the accidental tasksinordinately hard, such as severe hardware constraints, awkward programminglanguages, lack of machine time. How much of what software engineers now do isstill devoted to the accidental, as opposed to the essential? Unless it ismore than 9/10 of all effort, shrinking all the accidental activities to zerotime will not give an order of magnitude improvement.
Therefore it appears that the time has come to address the essential parts ofthe software task, those concerned with fashioning abstract conceptualstructures of great complexity. I suggest:
Of all the monsters who fill the nightmares of our folklore, none terrify morethan werewolves, because they transform unexpectedly from the familiar intohorrors. For these, we seek bullets of silver than can magically lay them torest.
The familiar software project has something of this character (at least asseen by the non-technical manager), usually innocent and straightforward, butcapable of becoming a monster of missed schedules, blown budgets, and flawedproducts. So we hear desperate cries for a silver bullet, something to makesoftware costs drop as rapidly as computer hardware costs do.
But, as we look to the horizon of a decade hence, we see no silver bullet.There is no single development, in either technology or management technique,which by itself promises even one order of magnitude improvement inproductivity, in reliability, in simplicity. In this chapter we shall try tosee why, but examining both the nature of the software problem and theproperties of the bullets proposed.
Skepticism is not pessimism, however. Although we see no startlingbreakthroughs, and indeed, believe such to be inconsistent with the nature ofsoftware, many encouraging innovations are under way. A disciplined,consistent effort to develop, propagate, and exploit them should indeed yieldan order-of-magnitude improvement. There is no royal road, but there is aroad.
The first step toward the management of disease was replacement of demontheories and humours theories by the germ theory. That very step, thebeginning of hope, in itself dashed all hopes of magical solutions. It toldworkers the progress would be made stepwise, at great effort, and that apersistent, unremitting care would have to be paid to a discipline ofcleanliness. So it is with software engineering today.
Not only are there no silver bullets now in view, the very nature of softwaremakes it unlikely that there will be any−no inventions that will do forsoftware productivity, reliability, and simplicity what electronics,transistors, and large-scale integration did for computer hardware. We cannotexpect ever to see twofold gains every two years.
First, we must observe that the anomaly is not that software progress is soslow but that computer hardware progress is so fast. No other technology sincecivilization began has seen six orders of magnitude price-performance gain in30 years. In no other technology can one choose to take the gain in eitherimproved performance or in reduced costs. These gains flow from thetransformation of computer manufacture from an assembly industry into aprocess industry.
Second, to see what rate of progress we can expect in software technology, letus examine its difficulties. Following Aristotle, I divide them intoessence−the difficulties inherent in the nature of the software−andaccidents−those difficulties that today attend its production but that are notinherent.
The accidents I discuss in the next section. First let us consider theessence.
The essence of a software entity is a construct of interlocking concepts: datasets, relationships among data items, algorithms, and invocations offunctions. This essence is abstract, in that the conceptual construct is thesame under many different representations. It is nonetheless highly preciseand richly detailed.
I believe the hard part of building software to be the specification, design,and testing of this conceptual construct, not the labor of representing it andtesting the fidelity of the representation. We still make syntax errors, to besure; but they are fuzz compared to the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently nosilver bullet.
Let us consider the inherent properties of this irreducible essence of modernsoftware systems: complexity, conformity, changeability, and invisibility.
Complexity. Software entities are more complex for their size than perhapsany other human construct, because no two parts are alike (at least above thestatement level). If they are, we make the two similar parts into one, asubroutine, open or closed. In this respect software systems differ profoundlyfrom computers, buildings, or automobiles, where repeated elements abound.
Digital computers are themselves more complex than most things people build;they have very large numbers of states. This makes conceiving, describing, andtesting them hard. Software systems have orders of magnitude more states thancomputers do.
Likewise, a scaling-up of a software entity is not merely a repetition of thesame elements in larger size; it is necessarily an increase in the number ofdifferent elements. In most cases, the elements interact with each other insome nonlinear fashion, and the complexity of the whole increases much morethan linearly.
The complexity of software is in essential property, not an accidental one.Hence descriptions of a software entity that abstract away its complexityoften abstract away its essence. Mathematics and the physical sciences madegreat strides for three centuries by constructing simplified models of complexphenomena, deriving properties from the models, and verifying those propertiesexperimentally. This worked because the complexities ignored in the modelswere not the essential properties of the phenomena. It does not work when thecomplexities are the essence.
Many of the classical problems of developing software products derived fromthis essential complexity and its nonlinear increased with size. From thecomplexity comes the difficulty of communication among team members, whichleads to product flaws, cost overruns, schedule delays. From the complexitycomes the difficulty of enumerating, much less understanding, all the possiblestates of the program, and from that comes the unreliability. From thecomplexity of the functions comes the difficulty of invoking those functions,which makes programs hard to use. From complexity of structure comes thedifficulty of extending programs to new functions without creating sideeffects. From the complexity of structure comes the unvisualized state thatthat constitute security trapdoors.
Not only technical problems but management problems as well come from thecomplexity. This complexity makes overview hard, thus impeding conceptualintegrity. It makes it hard to find and control all the loose ends. It createsthe tremendous learning and understanding burden that makes personnel turnovera disaster.
Conformity. Software people are not alone in facing complexity. Physicsdeals with terribly complex objects even at the “fundamental” particle level.The physicist labors on, however, in a firm faith that there are unifyingprinciples to be found, whether in quarks or in unified field theories.Einstein repeatedly argued that there must be simplified explanations ofnature, because God is not capricious or arbitrary.
No such faith comforts the software engineer. Much of the complexity he mustmaster is arbitrary complexity, forced without rhyme or reason by the manyhuman institutions and systems to which his interfaces must confirm. Thesediffer from interface to interface, and from time to time, not because ofnecessity but only because they were designed by different people, rather thanby God.
In many cases the software must confirm because it has most recently come tothe scene. In others it must conform because it is perceived as the mostconformable. But in all cases, much complexity comes from conformation toother interfaces; this cannot be simplified out by any redesign of thesoftware alone.
Changeability. The software entity is constantly subject to pressures forchange. Of course, so are buildings, cars, and computers. But manufacturedthings are infrequently changed after manufacture; they are superseded bylater models, or essential changes are incorporated in later serial-numbercopies of the same basic design. Callbacks of automobiles are really quiteinfrequent; field changes of computers somewhat less so. Both are much lessfrequent than modifications to fielded software.
Partly this is because the software in a system embodies its function, and thefunction is the part that most feels the pressures of change. Partly it isbecause software can be changed more easily−it is pure thought-stuff,infinitely malleable. Buildings do in fact get changed, but the high costs ofchange, understood by all, serve to dampen the whim of the changers.
All successful software gets changed. Two processes are at work. As a softwareproduct is found to be useful, people try it in new cases at the edge of, orbeyond, the original domain. The pressures for extended function come chieflyfrom users who like the basic function and invent new uses for it.
Second, successful software also survives beyond the normal life of themachine vehicle for which it is first written. If not new computers, then atleast new disks, new displays, new printers come along; and the software mustbe conformed to its new vehicles of opportunity.
In short, the software product is embedded in a cultural matrix ofapplications, users, laws, and machine vehicles. These all change continually,and their changes inexorably force change upon the software product.
Invisibility. Software is invisible and unvisualizable. Geometricabstractions are powerful tools. The floor plan of a building helps botharchitect and client evaluate spaces, traffic flows, and views. Contradictionsbecome obvious, omissions can be caught. Scale drawings of mechanical partsand stick-figure models of molecules, although abstractions, serve the samepurpose. A geometric reality is captured in a geometric abstraction.
The reality of software is not inherently embedded in space. Hence it has noready geometric representation in the way that land has maps, silicon chipshave diagrams, computers have connectivity schematics. As soon as we attemptto diagram software structure, we find it to constitute not one, but several,general directed graphs, superimposed one upon another. The several graphs mayrepresent the flow of control, the flow of data, patterns of dependency, timesequence, name-space relationships. These are usually not even planar, muchless hierarchical. Indeed, one of the ways of establishing conceptual controlover such structure is to enforce link cutting until one or more of the graphsbecomes hierarchical.2
In spite of progress in restricting and simplifying the structures ofsoftware, they remain inherently unvisualizable, thus depriving the mind ofsome of its most powerful conceptual tools. This lack not only impedes theprocess of design within one mind, it severely hinders communication amongminds.
If we examine the three steps in software technology that have been mostfruitful in the past, we discover that each attacked a different majordifficulty in building software, but they have been the accidental, not theessential, difficulties. We can also see the natural limits to theextrapolation of each such attack.
High-level languages. Surely the most powerful stroke for softwareproductivity, reliability, and simplicity has been the progressive use ofhigh-level languages for programming. Most observers credit that developmentwith at least a factor of five in productivity, and with concomitant gains inreliability, simplicity, and comprehensibility.
What does a high-level language accomplish? It frees a program from much ofits accidental complexity. An abstract program consists of conceptualconstructs: operations, data types, sequences, and communication. The concretemachine program is concerned with bits, registers, conditions, branches,channels, disks, and such. To the extent that the high-level language embodiesthe constructs wanted in the abstract program and avoids all lower ones, iteliminates a whole level of complexity that was never inherent in the programat all.
The most a high-level language can do is to furnish all the constructs theprogrammer imagines in the abstract program. To be sure, the level of oursophistication in thinking about data structures, data types, and operationsis steadily rising, but at an ever-decreasing rate. And language developmentapproaches closer and closer to the sophistication of users.
Moreover, at some point the elaboration of a high-level language becomes aburden that increases, not reduces, the intellectual task of the user whorarely uses the esoteric constructs.
Time-sharing. Most observers credit time-sharing with a major improvementin the productivity of programmers and in the quality of their product,although not so large as that brought by high-level languages.
Time-sharing attacks a distinctly different difficulty. Time-sharing preservesimmediacy, and hence enables us to maintain an overview of complexity. Theslow turnaround of batch programming means that we inevitably forget theminutiae, if not the very thrust, of what we were thinking when we stoppedprogramming and called for compilation and execution. This interruption ofconsciousness is costly in time, for we must refresh. The most serious effectmay well be the decay of grasp of all that is going on in a complex system.
Slow turn-around, like machine-language complexities, is an accidental ratherthan an essential difficulty of the software process. The limits of thecontribution of time-sharing derive directly. The principle effect is toshorten system response time. As it goes to zero, at some point it passes thehuman threshold of noticeability, about 100 milliseconds. Beyond that nobenefits are to be expected.
Unified programming environments. Unix and Interlisp, the first integratedprogramming environments to come into widespread use, are perceived to haveimproved productivity by integral factors. Why?
They attack the accidental difficulties of using programs together, byproviding integrated libraries, unified file formats, and piles and filters.As a result, conceptual structures that in principle could always call, feed,and use one another can indeed easily do so in practice.
This breakthrough in turn stimulated the development of whole toolbenches,since each new tool could be applied to any programs by using the standardformats.
Because of these successes, environments are the subject of much of today’ssoftware engineering research. We will look at their promise and limitationsin the next section.
Now lets us consider the technical developments that are most often advancedas potential silver bullets. What problems do they address? Are they theproblems of essence, or are they remainders of our accidental difficulties? Dothey offer revolutionary advances, or incremental ones?
Ada and other high-level language advances. One of the most touted recentdevelopments is the programming language Ada, a general-purpose, high-levellanguage of the 1980s. Ada indeed not only reflects evolutionary improvementsin language concepts but embodies features to encourage modern design andmodularization concepts. Perhaps the Ada philosophy is more of an advance thanthe Ada language, for it is the philosophy of modularization, of abstract datatypes, of hierarchical structuring. Ada is perhaps over-rich, the naturalproduct of the process by which requirements were laid on its design. That isnot fatal, for subset working vocabularies can solve the learning problem, andhardware advances will give us the cheap MIPS to pay for the compiling costs.Advancing the structuring of software systems is indeed a very good use forthe increased MIPS our dollars will buy. Operating systems, loudly decried inthe 1960s for their memory and cycle costs, have proved to be an excellentform in which to use some of the MIPS and cheap memory bytes of the pasthardware surge.
Nevertheless, Ada will not prove to be the silver bullet that slays thesoftware productivity monster. It is, after all, just another high-levellanguage, and the biggest payoff from such languages came from the firsttransition, up from the accidental complexities of the machine into the moreabstract statement of step-by-step solutions. Once those accidents have beenremoved, the remaining ones are smaller, and the payoff from their removalwill surely be less.
I predict that a decade from now, when the effectiveness of Ada is assessed,it will be seen to have made a substantial difference, but not because of anyparticular language feature, nor indeed because of all of them combined.Neither will the new Ada environment prove to be the cause of theimprovements. Ada’s greatest contribution will be that switching to itoccasioned training programmers in modern software design techniques.
Object-oriented programming. Many students of the art hold out more hopefor object-oriented programming than for any of the other technical fads ofthe day.3 I am among them. Mark Sherman of Dartmouth notes that we must becareful to distinguish two separate ideas that go under that name: abstractdata types and hierarchical types, also called classes. The concept of theabstract data type is that an object’s type should be defined by a name, a setof proper values, and a set of proper operations, rather than its storagestructure, which should be hidden. Examples are Ada packages (with privatetypes) or Modula’s modules.
Hierarchical types, such as Simula-67’s classes, allow the definition ofgeneral interfaces that can be further refined by providing subordinate types.The two concepts are orthogonal−there may be hierarchies without hiding andhiding without hierarchies. Both concepts represent real advances in the artof building software.
Each removes one more accidental difficulty from the process, allowing thedesigner to express the essence of his design without having to express largeamounts of syntactic material that add no new information content. For bothabstract types and hierarchical types, the result is to remove a higher-ordersort of accidental difficulty and allow a higher-order expression of design.
Nevertheless, such advances can do no more than to remove all the accidentaldifficulties from the expression of the design. The complexity of the designitself is essential; and such attacks make no change whatever in that. Anorder-of-magnitude gain can be made by object-oriented programming only if theunnecessary underbrush of type specification remaining today in ourprogramming language is itself responsible for nine-tenths of the workinvolved in designing a program product. I doubt it.
Artificial intelligence. Many people expect advances in artificialintelligence to provide the revolutionary breakthrough that will giveorder-of-magnitude gains in software productivity and quality.4 I do not.To see why, we must dissect what is meant by “artificial intelligence” andthen see how it applies.
Parnas has clarified the terminological chaos:
Two quite different definitions of AI are in common use today. AI-1: Theuse of computers to solve problems that previously could only be solved byapplying human intelligence. AI-2: The use of a specific set of programmingtechniques knows as heuristic or rule-based programming. In this approachhuman experts are studies to determine what heuristics or rules of thumbthey use in solving problems. . . . The program is designed to solve aproblem the way that humans seem to solve it.
The first definition has a sliding meaning. . . . Something can fit thedefinition of AI-1 today but, once we see how the program works andunderstand the problem, we will not think of it as AI anymore. . . .Unfortunately I cannot identify a body of technology that is unique to thisfield. . . . Most of the work is problem-specific, and some abstraction orcreativity is require to see how to transfer it.5
I agree completely with this critique. The techniques used for speechrecognition seem to have little in common with those used for imagerecognition, and both are different from those used in expert systems. I havea hard time seeing how image recognition, for example, will make anyappreciable difference in programming practice. The same is try of speechrecognition. The hard thing about building software is deciding what to say,not saying it. No facilitation of expression can give more than marginalgains.
Expert systems technology, AI-2, deserves a section of its own.
Expert systems. The most advanced part of the artificial intelligence art,and the most widely applies, is the technology for building expert systems.Many software scientists are hard at work applying this technology to thesoftware-building environment.6 What is the concept, and what are theprospects?
An expert system is a program containing a generalized inference engine and arule base, designed to take input data and assumptions and explore the logicalconsequences through the inferences derivable from the rule base, yieldingconclusions and advice, and offering to explain its results by retracing itsreasoning for the user. The inference engines typically can deal with fuzzy orprobabilistic data and rules in addition to purely deterministic logic.
Such systems offer some clear advantages over programmed algorithms forarriving at the same solutions to the same problems:
Edward Feigenbaum says that the power of such systems does not come fromever-fancier inference mechanisms, but rather from ever-richer knowledge basesthat reflect the real world more accurately. I believe the most importantadvance offered by the technology is the separation of the applicationcomplexity from the program itself.
How can this be applied to the software task? In many ways: suggestinginterface rules, advising on testing strategies, remembering but-typefrequencies, offering optimization hints, etc.
Consider an imaginary testing advisor, for example. In its most rudimentaryform, the diagnostic expert system is very like a pilot’s checklist,fundamentally offering suggestions as to possible causes of difficulty. As therule base is developed, the suggestions become more specific, taking moresophisticated account of the trouble symptoms reported. One can visualize adebugging assistant that offers very generalized suggestions at first, but asmore and more system structure is embodied in the rule base, comes more andmore particular in the hypotheses is generates and the tests it recommends.Such an expert system may depart most radically from the conventional ones inthat its rule base should probably be hierarchically modularized in the sameway the corresponding software product is, so that as the product is modularlymodified, the diagnostic rule base can be modularly modified as well.
The work required to generate the diagnostic rules is work that will have tobe done anyway in generating the set of test cases for the modules and for thesystem. If it is done in a suitably general manner, with a uniform structurefor rules and a good inference engine available, it may actually reduce thetotal labor of generating bring-up test cases, as well as helping in lifelongmaintenance and modification testing. In the same way, we can postulate otheradvisors probably many of them and probably simple ones for the other parts ofthe software construction task.
Many difficulties stand in the way of early realization of useful expertadvisors to the program developer. A crucial part of our imaginary scenario isthe development of easy ways to get from program structure specification tothe automatic or semi-automatic generation of diagnostic rules. Even moredifficult and important is the twofold task of knowledge acquisition: findingarticulate, self-analytical experts who know why they do things; anddeveloping efficient techniques for extracting what they know and distillingit into rule bases. The essential prerequisite for building an expert systemis to have an expert.
The most powerful contribution of expert systems will surely be to put at theservice of the inexperienced programmer the experience and accumulated wisdomof the best programmers. This is no small contribution. The gap between thebest software engineering practice and the average practice is verywide−perhaps wider than in any other engineering discipline. A tool thatdisseminates good practice would be important.
“Automatic” programming. For almost 40 years, people have beenanticipating and writing about “automatic programming”, the generation of aprogram for solving a problem from a statement of the problem specifications.Some people today write as if they expected this technology to provide thenext breakthrough.7
Parnas implies that the term is used for glamour and not semantic content,asserting,
In short, automatic programming always has been a euphemism for programmingwith a higher-level language than was presently available to theprogrammer.8
He argues, in essence, that in most cases it is the solution method, not theproblem, whose specification has to be given.
Exceptions can be found. The technique of building generators is verypowerful, and it is routinely used to good advantage in programs for sorting.Some systems for integrating differential equations have also permitted directspecification of the problem. The system assessed the parameters, chose from alibrary of methods of solution, and generated the programs.
It is hard to see how such techniques generalize to the wider world of theordinary software system, where cases with such neat properties are theexception. It is hard even to imagine how this breakthrough in generalizationcould conceivably occur.
Graphical programming. A favorite subject for PH.D. dissertations insoftware engineering is graphical, or visual, programming, the application ofcomputer graphics to software design.9 Sometimes the promise of such anapproach is postulated from the analogy with VLSI chip design, where computergraphics plays so fruitful a role. Sometimes the approach is justified byconsidering flowcharts as the ideal program design medium, and providingpowerful facilities for constructing them.
Nothing even convincing, much less exciting, has yet emerged from suchefforts. I am persuaded that nothing will.
In the first place, as I have argued elsewhere, the flow chart is a very poorabstraction of software structure.10 Indeed, it is best viewed as Burks,von Neumann, and Goldstine’s attempt to provide a desperately neededhigh-level control language for their proposed computer. In the pitiful,multipage, connection-boxed form to which the flow chart has today beenelaborated, it has proved to be essentially useless as a design-toolprogrammers draw flow charts after, not before, writing the programs theydescribe.
Second, the screens of today are too small, in pixels, to show both the scopeand the resolution of any serious detailed software diagram. The so-called“desktop metaphor” of today’s workstation is instead an “airplane-seat”metaphor. Anyone who has shuffled a lapful of papers while seated in a coachbetween two portly passengers will recognize the difference−one can see only avery few things at once. The true desktop provides overview of and randomaccess to a score of pages. Moreover, when fits of creativity run strong, morethan one programmer or writer has been known to abandon the desktop for themore spacious floor. The hardware technology will have to advance quitesubstantially before the scope of our scopes is sufficient to the softwaredesign task.
More fundamentally, as I have argued above, software is very difficult tovisualize. Whether we diagram control flow, variable scope nesting, variablecross-references, data blow, hierarchical data structures, or whatever, wefeel only one dimension of the intricately interlocked software elephant. Ifwe superimpose all the diagrams generated by the many relevant views, it isdifficult to extract any global overview. The VLSI analogy is fundamentallymisleading−a chip design is a layered two-dimensional object whose geometryreflects its essence. A software system is not.
Program verification. Much of the effort in modern programming goes intothe testing and repair of bugs. Is there perhaps a silver bullet to be foundby eliminating the errors at the source, in the system design phase? Can bothproductivity and product reliability be radically enhance by following theprofoundly different strategy of proving designs correct before the immenseeffort is poured into implementing and testing them?
I do not believe we will find the magic here. Program verification is a verypowerful concept, and it will be very important for such things as secureoperating system kernels. The technology does not promise, however, to savelabor. Verifications are so much work that only a few substantial programshave ever been verified.
Program verification does not mean error-proof programs. There is no magichere, either. Mathematical proofs also can be faulty. So whereas verificationmight reduce the program-testing load, it cannot eliminate it.
More seriously, even perfect program verification can only establish that aprogram meets its specification. The hardest part of the software task isarriving at a complete and consistent specification, and much of the essenceof building a program is in fact the debugging of the specification.
Environments and tools. How much more gain can be expected from theexploding researches into better programming environments? One’s instinctivereaction is that the big-payoff problems were the first attacked, and havebeen solved: hierarchical file systems, uniform file formats so as to haveuniform program interfaces, and generalized tools. Language-specific smarteditors are developments not yet widely used in practice, but the most theypromise is freedom from syntactic errors and simple semantic errors.
Perhaps the biggest gain yet to be realized in the programming environment isthe use of integrated database systems to keep track of the myriads of detailsthat must be recalled accurately by the individual programmer and kept currentin a group of collaborators on a single system.
Surely this work is worthwhile, and surely it will bear some fruit in bothproductivity and reliability. But by its very nature, the return from now onmust be marginal.
Workstations. What gains are to be expected for the software art from thecertain and rapid increase in the power and memory capacity of the individualworkstation? Well, how many MIPS can one use fruitfully? The composition andediting of programs and documents is fully supported by today’s speeds.Compiling could stand a boost, but a factor of 10 in machine speed wouldsurely leave think-time the dominant activity in the programmer’s day. Indeed,it appears to be so now.
More powerful workstations we surely welcome. Magical enhancements from themwe cannot expect.
Even though no technological breakthrough promises to give the soft of magicalresults with which we are so familiar in the hardware area, there is both anabundance of good working going on now, and the promise of steady, ifunspectacular progress.
All of the technological attacks on the accidents of the software process arefundamentally limited by the productivity equation:
Time of task = ∑ (Frequency)ᵢ x (Time)ᵢ
If, as I believe, the conceptual components of the task are now taking most ofthe time, then no amount of activity on the task components that are merelythe expression of the concepts can give large productivity gains.
Hence we must consider those attacks that address the essence of the softwareproblem, the formulation of these complex conceptual structures. Fortunately,some of these are very promising.
Buy versus build. The most radical possible solution for constructingsoftware is not to construct it at all.
Every day this becomes easier, as more and more vendors offer more and bettersoftware products for a dizzying variety of applications. While we softwareengineers have labored on production methodology, the personal computerrevolution has created not one, but m any, mass markets for software. Everynewsstand carried monthly magazines which, sorted by machine type, advertiseand review dozens of products at prices from a few dollars to a few hundreddollars. More specialized sources offer very powerful products for theworkstation and other Unix markets. Even software tolls and environments canbe bought off-the-shelf. I have elsewhere proposed a market place forindividual modules.
Any such product is cheaper to buy than to build afresh. Even at a cost of$100,000, a purchased piece of software is costing only about as much as oneprogrammer-year. And delivery is immediate! Immediate at least for productsthat really exist, products whose developer can refer the prospect to a happyuser. Moreover, such products tend to be much better documented and somewhatbetter maintained than homegrown software.
The development of the mass market is, I believe, the most profound long-runtrend in software engineering. The cost of software has always beendevelopment cost, not replication cost. Sharing that cost among even a fewusers radically cuts the per-user cost. Another way of looking at it is thatthe use of n copies of a software system effectively multiplies theproductivity of its developers by n. That is an enhancement of theproductivity of the discipline and of the nation.
The key issue, of course, is applicability. Can I use an availableoff-the-shelf package to do my task? A surprising thing has happened here.During the 1950s and 1960s, study after study showed that users would not useoff-the-shelf packages for payroll, inventory control, accounts receivable,etc. The requirements were too specialized, the case-to-case variation toohigh. During the 1980s, we find such packages in high demand and widespreaduse. What has changed?
Not really the packages. They may be somewhat more generalized and somewhatmore customizable than formerly, but not much. Not really the applications,either. If anything, the business and scientific needs of today are morediverse, more complicated than those of 20 years ago.
The big change has been in the hardware/software cost ratio. The buyer of a$2-million machine in 1960 felt that he could afford $250,000 more for acustomized payroll program, one that slipped easily and nondisruptively intothe computer-hostile social environment. Buyers of $50,000 office machinestoday cannot conceivably afford customized payroll programs; so they adapttheir payroll procedures to the packages available. Computers are now socommonplace, if not yet so beloved, that the adaptations are accepted as amatter of course.
There are dramatic exceptions to my argument that the generalization of thesoftware packages has changed little over the years: electronic spreadsheetsand simple database systems. These powerful tools, so obvious in retrospectand yet so late appearing, lend themselves to myriad uses, some quiteunorthodox. Articles and even books now abound on how to tackle unexpectedtasks with the spreadsheet. Large numbers of applications that would formerlyhave been written as custom programs in Cobol or Report Program Generator arenow routinely done with these tools.
Many users now operate their own computers day in and day out on variedapplications without ever writing a program. Indeed, many of these userscannot write new programs for their machines, but they are nevertheless adeptat solving new problems with them.
I believe the single most powerful software productivity strategy for manorganizations to day is to equip the computer-naïve intellectual workers onthe firing line with personal computers and good generalized writing, drawing,file and spreadsheet programs, and turn them loose. The same strategy, withsimple programming capabilities, will also work for hundreds of laboratoryscientists.
Requirements refinement and rapid prototyping. The hardest single part ofbuilding a software system is deciding precisely what to build. No other partof the conceptual work is to difficult as establishing the detailed technicalrequirements, including all the interfaces to people, to machines, and toother software systems. No other part of the work so cripples the resultingsystem if done wrong. No other part is more difficult go rectify later.
Therefore the most important function that software builders do for theirclients is the iterative extraction and refinement of the productrequirements. For the truth is, the clients do not know what they want. Theyusually do not know what questions must be answered, and they almost neverhave thought of the problem in the detail that must be specified. Even thesimple answer−”Make the new software system work like our old manualinformation-processing system” −is in fact too simple. Clients never wantexactly that. Complex software systems are, moreover, things that act, thatmove, that work. The dynamics of that action are hard to imagine. So inplanning any software activity, it is necessary to allow for an extensiveiteration between the client and the designer as part of the systemdefinition.
I would go a step further and assert that it is really impossible for clients,even those working with software engineers, to specify completely, precisely,and correctly the exact requirements of a modern software product beforehaving built and tried some versions of the product they are specifying.
Therefore one of the most promising of the current technological efforts, andone which attacks the essence, not the accidents, of the software problem, isthe development of approaches and tools for rapid prototyping of systems aspart of the iterative specification of requirements.
A prototype software system is one that simulates the important interfaces andperforms the main functions of the intended system, while not beingnecessarily bound by the same hardware speed, size, or cost constraints.Prototypes typically perform the mainline tasks of the application, but makeno attempt to handle the exceptions, respond correctly to invalid inputs,abort cleanly, etc. The purpose of the prototype is to make real theconceptual structure specified, so that the client can test it for consistencyand usability
Much of present-day software acquisition procedures rests upon the assumptionthat one can specify a satisfactory system in advance, get bids for itsconstruction, have it built, and install it. I think this assumption isfundamentally wrong, and that many software acquisition problems spring fromthat fallacy. Hence they cannot be fixed without fundamental revision, onethat provides for iterative development and specification of prototypes andproducts.
Incremental development−grow, not build, software. I still remember thejolt I felt in 1958 when I first heard a friend talk about building aprogram, as opposed to writing one. In a flash be broadened my whole view ofthe software process. The metaphor shift was powerful, and accurate. Today weunderstand how like other building processes the construction of software is,and we freely use other elements of the metaphor, such as specifications,assembly of components, and scaffolding.
The building metaphor has outlived its usefulness. It is time to change again.If, as I believe, the conceptual structures we construct today are toocomplicated to be accurately specified in advance, and too complex to be builtfaultlessly, then we must take a radically different approach.
Let us turn to nature and study complexity in living things, instead of justthe dead works of man. Here we find constructs whose complexities thrill uswith awe. The brain alone is intricate beyond mapping, powerful beyondimitation, rich in diversity, self-protecting, and self-renewing. The secretis that it is grown, not built.
So it must be with our software systems. Some years ago Harlan Mills proposedthat any software system should be grown by incremental development.11 Thatis, the system should first be made to run, even though it does nothing usefulexcept call the proper set of dummy subprograms. Then, bit-by-bit it isfleshed out, with the subprograms in turn being developed into actions orcalls to empty stubs in the level below.
I have seen the most dramatic results since I began urging this technique onthe project builders in my software engineering laboratory class. Nothing inthe past decade has so radically changed my own practice, or itseffectiveness. The approach necessitates top-down design, for it is a top-downgrowing of the software. It allows easy backtracking. It lends itself to earlyprototypes. Each added function and new provision for more complex data orcircumstances grown organically out of what is already there.
The morale effects are startling. Enthusiasm jumps when there is a runningsystem, even a simple one. Efforts redouble when the first picture from a newgraphics software system appears on the screen, even if it is only arectangle. One always has, at every stage in the process, a working system. Ifind that teams can grow much more complex entities in four months than theycan build.
The same benefits can be realized on large projects as on my small ones.12
Great designers. The central question of how to improve the software artcenters, as it always, on people.
We can get good designs by following good practices instead of poor ones. Gooddesign practices can be taught. Programmers are among the most intelligentpart of the population, so they can learn good practice. Thus a major thrustin the United States is to promulgate good modern practice. New curricula, newliterature, new organizations such as the Software Engineering Institute, allhave come into being in order to raise the level of our practice from poor togood. This is entirely proper.
Nevertheless, I do not believe we can make the next step upward in the sameway. Whereas the difference between poor conceptual designs and good ones maylie in the soundness of design method, the difference between good designs andgreat ones surely does not. Great designs come from great designers. Softwareconstruction is a creative process. Sound methodology can empower and liberatethe creative mind; it cannot enflame or inspire the drudge.
The differences are not minor−it is rather like Salieri and Mozart. Studyafter study shows that the very best designers produce structures that arefaster, smaller, simpler, cleaner, and produced with less effort. Thedifferences between the great and the average approach an order of magnitude.
A little retrospection shows that although many fine, useful software systemshave been designed by committees and built by multipart projects, thosesoftware systems that have excited passionate fans are those that are theproducts of one or a few designing minds, great designers. Consider Unix, APL,Pascal, Modula, the Smalltalk interface, even Fortran; and contrast withCobol, PL/I, Algol, MVS/370, and MS-DOS (fig. 1)
| Yes | No |
|---|---|
| Unix | Cobol |
| APL | PL/1 |
| Pascal | Algol |
| Modula | MVS/370 |
| Smalltalk | MS-DOS |
| Fortran |
Fig. 1 Exciting products
Hence, although I strongly support the technology transfer and curriculumdevelopment efforts now underway, I think the most important single effort wecan mount is to develop ways to grow great designers.
No software organization can ignore this challenge. Good managers, scarcethough they be, are no scarcer than good designers. Great designers and greatmanagers are both very rare. Most organizations spend considerable effort infinding and cultivating the management prospects; I know of none that spendsequal effort in finding and developing the great designers upon whom thetechnical excellence of the products will ultimately depend.
My first proposal is that each software organization must determine andproclaim that great designers are as important to its success as greatmanagers are, and that they can be expected to be similarly nurtured andrewarded. Not only salary, but the perquisites of recognition−office size,furnishings, personal technical equipment, travel funds, staff support−must befully equivalent.
How to grow great designers? Space does not permit a lengthy discussion, butsome steps are obvious:
■
Reproduced from: Frederick P. Brooks, The Mythical Man-Month,Anniversary edition with 4 new chapters, Addison-Wesley (1995), itselfreprinted from the Proceedings of the IFIP Tenth World ComputingConference, H.-J. Kugler, ed., Elsevier Science B.V., Amsterdam, NL(1986) pp. 1069-76. ↩
Parnas, D.L., “Designing software for ease of extension andcontraction,” IEEE Trans. on SE, 5, 2 (March, 1979), pp. 12-138. ↩
Booch, G., “Object-oriented design,” in Software Engineering with Ada.Menlo Park, Calif.: Benjamin Cummings, 1983. ↩
Mostow, J., ed., Special Issue on Artifical Intelligence and SoftwareEngineering, IEEE Trans. on SE, 11, 11 (nov. 1985). ↩
Parnas, D.L., “Software aspects of strategic defense systems,”Communications of the ACM, 28, 12 (Dec., 1985), pp. 1326-1335. Also inAmerican Scientist, 73, 5 (Sept.-Oct., 1985), pp. 432-440. ↩
Balzer, R., “A 15-year perspective on automatic programming,” in Mostow,op. cit. ↩
Mostow, op. cit. ↩
Parnas, 1985, op. cit. ↩
Raeder, G., “A survey of current graphical programming techniques,” inR. B. Grafton and T. Ichikawa, eds., Special Issue on Visual Programming,Computer, 18, 8 (Aug., 1985), pp. 11-25 ↩
Brooks 1995, op. cit., chapter 15. ↩
Mills, H. D., “Top-down programming in large systems,” DebuggingTechniques in Large Systems, R. Rustin, ed., Englewood Cliffs, N.J.,Prentice-Hall, 1971. ↩
Boehm, B. W., “A spiral model of software development and enhancement,”Computer, 20, 5 (May, 1985), pp. 43-57. ↩
Put an electric light above a workbench and the work can continue after sunset. Put it above a kitchen table and someone can read a book, teach a child, or draw something that has no customer.
The technology makes both possible. The arrangement of life around it determines which possibility people get to enjoy.
I think this is the part of technological change we keep leaving unfinished. We learn to explain something. We learn to build with it. We make it useful, affordable, and available. Then we announce a revolution, even while people are struggling to find their place in the world we have changed.
A technological transformation remains unfinished while its capabilities exceed our ability to turn them into a life people can help shape.
There is a cycle here:
Science → Engineering → Product → Art, Meaning, and Dignity → New Questions → Science
Science expands what we understand. Engineering turns understanding into practical capability. Products give that capability a form people can use. Then people interpret what has become possible, question what it is doing to them, and decide what deserves a place in their lives. Those experiences give rise to new questions, some of which become the starting point for another round of discovery.
Neri Oxman offered a close relative of this model in her Krebs Cycle of Creativity, connecting science, engineering, design, and art. Her framework describes how these activities feed one another. The question I want to follow is what happens when a society becomes very good at producing capability and struggles to give people a meaningful part in deciding what it is for.
These activities overlap. People made art long before modern science, and practical craft often developed ahead of scientific explanation. Dignity belongs to people throughout the cycle. It is an obligation we carry into the transformation.
What changes is the setting in which people try to exercise their imagination, find purpose, and live with one another.
Between each part of the cycle, possibility can accumulate faster than we learn to use it. I find it useful to call these gaps overhangs. They are the difference between what has become possible and what the next part of our world can absorb.
The first overhang sits between science and engineering.
Knowing why something should work leaves a great deal of work before anyone can depend on it. A promising result must survive different conditions. Materials must behave. Costs must come down. Someone has to discover what breaks after the thousandth repetition.
James Watt’s separate condenser is a useful reminder. The idea greatly improved the efficiency of the steam engine, but turning it into a practical industrial machine required years of work. The surviving models record that passage from insight to dependable machinery. The Science Museum’s account makes visible the effort hidden inside the familiar story of an invention.
AI has its own version of this gap. An impressive answer raises different questions from a dependable service. Under what conditions does it work? How do we recognize failure? What will it cost to check, repair, and operate? Engineering has to establish those boundaries.
That work deserves respect. Reliability is one of the ways we care for people who will never meet the person who designed the system.
The second overhang sits between engineering and product.
A capability can work and still be difficult to use, maintain, obtain, or fit into ordinary life. By product, I mean the usable form of a capability: a tool, a service, an application, or shared infrastructure. Design connects what the machinery can do with what a person needs to accomplish.
Electrification shows how much can live inside this gap. Small electric motors allowed factory equipment to be arranged around the flow of work rather than the location of shafts and belts. Realizing that possibility involved changing the factory around the motor. Wiring, equipment, and working arrangements had to come together. The Smithsonian’s history of electrification follows those connections into both factories and homes.
I explored the organizational part of this problem in Beyond the Light Bulb. Giving people an AI tool can improve individual tasks while the larger process continues to wait for information, decisions, or permission. The tool has arrived. The organization is still learning how to make use of it.
Research on the Productivity J-Curve gives this a broader economic foundation. General-purpose technologies require complementary investments, including investments that are difficult to see in conventional accounts. Buying the visible technology is only part of the work.
But even successful adoption leaves the third overhang.
This is the gap between useful products and a culture in which people can find art, meaning, and dignity.
It is the gap that concerns me most.
Suppose a team establishes that AI allows it to complete the same accepted work with less effort. What happens to the recovered capacity? The organization might serve more people, improve quality, reduce prices, give employees time to learn, shorten working hours, reduce headcount, or increase returns to its owners. It might choose some combination.
The tool does not determine that decision. People with different interests must make it.
In When Output Becomes Abundant, I wrote about how a production bottleneck can move toward judgment, coordination, and trust. The same question reaches beyond the organization. Once we can make more, we still have to decide what is worth making, who benefits, and what happens to the people whose contribution has changed.
More capability gives us more choices. It also makes the choices we avoid more consequential.
This problem reaches much further back than AI.
Agriculture changed the possibilities of settlement, storage, and specialization. It also created recurring questions about who controlled a harvest and what obligations surrounded it. Archaeological research cautions against treating greater productivity as an automatic cause of greater inequality. The relationship depended on human action and institutions. The history is more varied than a single ladder of progress allows.
Writing and printing changed the possibilities of preserving, sharing, and disputing knowledge. Their cultural purposes also helped drive their development. In China, the reproduction of Buddhist texts and images helped advance printing, which later became a medium for artistic expression and social commentary. The Met’s history of the printed image shows belief, technique, commerce, and art developing through one another.
In sixteenth-century Europe, the printed anatomical illustrations in Vesalius’s On the Fabric of the Human Body brought observation, image-making, and medical education together. The book helped readers see the body differently, and its woodcuts also attracted an audience beyond medicine. Here the cycle was already moving in several directions at once. The Library of Congress describes that exchange.
The Industrial Age made the human consequences of these gaps especially difficult to ignore.
Factories could produce more while the people inside them worked under conditions that demanded reform. In Britain, campaigns, parliamentary investigations, legislation, and inspection all played a part in changing those conditions. The 1833 Factory Act placed limits on children’s work and established an inspectorate, although enforcement remained inadequate.
Those protections had to be argued for, organized, funded, and enforced.
The machinery did not contain a schedule for when its benefits would become a better childhood or a more humane working day.
William Morris approached industrial civilization from another direction. He asked what had happened to the relationship between making something and taking pleasure in making it. His concern included the finished object, the condition of its maker, and the possibility of beauty in ordinary life. In Art and Labour, he used art in a broad sense that reached into how people worked and experienced the world around them.
The Arts and Crafts movement made that relationship a public question. Its participants wanted objects with integrity and ways of producing them that left their makers connected to the work.
We can learn from that question without adopting every proposed answer. Returning to an earlier method does not by itself restore agency or make good work widely available. In A Letter to the Artisanal Software Craftsman, I argued that craft can travel into new methods through judgment, care, and responsibility.
That argument also creates an obligation for leaders. If we ask people to carry their craft into a new system, we owe them a voice in shaping it and a real opportunity to learn.
Electricity offers a quieter warning about the same overhang. Appliances reduced the effort of particular household tasks, yet the time spent on housework did not necessarily fall as expectations changed. A technical saving can be absorbed by a new standard of performance. The machine works better, and the person remains just as occupied. The Smithsonian records that tension in the history of domestic electrification.
Computing and networks brought another set of possibilities. People began forming communities through shared computer systems in the 1960s, long before today’s social platforms. Communication and belonging were part of what people wanted these machines to make possible. The Computer History Museum’s account follows that history from early messaging into online communities.
Across mechanization, steam, electricity, mass production, automobiles, and information technology, new capabilities have repeatedly required changes in the world around them. Carlota Perez’s work on technological revolutions places particular attention on the institutional choices that shape how widely their benefits spread.
That is the historical lesson I would carry into AI: the arrangements matter, and we can change them.
We currently occupy several overhangs at once. Some AI applications need better science. Others need more dependable engineering. Some useful tools still need better design, access, and support. Meanwhile, questions about livelihoods, participation, ownership, and purpose are already present.
We cannot postpone those questions until the technology is finished.
AI is also unusual in how visibly it works across the cycle. It is an object of scientific inquiry, an engineered system, a product people use, and a medium for expression. Researchers are examining whether it can also change the methods through which further inventions emerge. A 2026 economics paper argues that generative AI may function both as a general-purpose technology and as a change in the methods of invention.
That possibility makes the cultural questions more urgent. We need to help direct a process that may keep expanding what it can do.
Producing more images, songs, and stories is one part of that process. The art phase asks what people can express through these tools, what they come to notice, and whether their encounters with one another become richer.
A small experiment in short-story writing illustrates the tension. Access to AI-generated ideas improved how individual stories were evaluated, while the assisted stories became more similar to one another. The finding comes from a bounded writing task, but it gives us something concrete to consider: individual assistance and collective variety can move differently. Doshi and Hauser’s study leaves room for both the promise and the difficulty.
Art helps us attend to experience. A story can make a familiar arrangement seem strange enough to question. A song can give people language for something they felt but could not explain. Making something can become a way of discovering what we care about.
Meaning grows through relationships, purposes, and commitments. It includes being able to contribute and having some influence over what happens because we are there.
Dignity reaches deeper. A person’s claim to respect and a place among other people persists when the market stops purchasing a skill they spent years learning.
These belong together, but they are different needs. A beautiful cultural product does not establish that its makers were treated well. A full calendar does not establish that someone’s work has purpose. A new job title does not settle whether a person has any real influence.
In Beyond the Mirror, I argued for shared purpose, a living commons, coordinated autonomy, and shared gains. Those commitments become more demanding when we carry them from a team into society.
Who helps decide which work to automate? How can people question the decisions that affect their livelihood? What support exists while they learn something new? Where will recovered time appear in an actual human life?
Answering those questions is how we begin closing the third overhang.
That requires material conditions as well as encouraging language. People need security while roles change. Learning needs paid time and opportunities to practice. Workers and communities affected by automation need influence early enough to shape decisions. Shared gains need a visible form: better services, greater security, wider access, improved pay, or time people can direct themselves.
The cultural institutions around that life matter too. Libraries, schools, workshops, parks, and places where people gather give possibility somewhere to develop. Affordable access to useful tools matters. So does the freedom to make something without first proving that someone will buy it.
A person might use that freedom to write a novel, repair bicycles, care for a neighbor, grow vegetables, or become a little better at playing the piano. They should be able to discover what matters through living.
If we describe every recovered hour as spare capacity waiting for another assignment, we have already made a decision about what technology is for.
There is a fourth overhang, and it brings us around the cycle again.
People can notice a problem or imagine a possibility long before it receives sustained investigation. A community may understand that a service excludes it while lacking the resources to study an alternative. Someone doing the work may see a better question but have no route to the people authorized to pursue it.
Art changes what we notice. Meaning helps shape what we choose to pursue. Dignity broadens who gets to ask and whose experience deserves attention.
That is one way cultural life feeds discovery.
Some questions become experiments and research programs. Others remain questions of value that we must work through together. Science can inform a choice without making the choice for us.
In my earlier writing on the art of the possible, I worried about what happens when familiar constraints become the limits of our imagination. The cycle needs people who can recognize a constraint, understand it, and still ask whether we should build something different.
It also needs room for inquiry whose use is unclear. Art has value in the experience itself. Curiosity can be worth sustaining before it offers a commercial return. We should leave people enough freedom to follow a question beyond the point where its value fits neatly into a business case.
Years ago, writing about defending the commons, I used a garden to distinguish the community, the resource it tends, and the fruit it produces. The gardeners, the garden, and the harvest are different things.
AI may help us make the garden more productive. We still have to care for the people who tend it, decide how its fruit is shared, and leave room for something planted simply because someone hopes it will bloom.
That is the cultural transformation we must make a public goal. We need institutions in which greater capability becomes greater opportunity to learn, contribute, belong, and shape a life. We need to protect dignity while the work changes, and give art and meaning a place in the decisions that direct the change.
The light above the workbench can stay on all night.
We should build a world in which the person working there can finish, go home, and turn on another light over a table of their own. There might be a book waiting, a child with a question, or a drawing they have been meaning to begin.
We cannot know in advance what they will discover there. We can make sure they have a chance.
", "url": "https://tedt.org/The-Unfinished-Revolution/", "image": "/img/2026-10/The-Unfinished-Revolution.webp", "tags": ["AI and society","technological change","human dignity","creativity","culture","productivity"], "date_published": "2026-10-25T00:00:00-07:00", "date_modified": "2026-10-25T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/The-Business-Transformation-Has-Become-a-Software-Process/", "title": "The Business Transformation has become a Software Process", "summary": "Business transformation depends on the ability to keep changing software. AI changes the development process, but maintenance, testing, and team learning remain continuing responsibilities.", "content_text": "The Business Transformation has become a Software ProcessBusiness transformation depends on software we can keep changing. AI is changing how we build and maintain that capability.Suppose a distributor wants to let customers change tomorrow’s delivery without making a phone call.The customer portal already exists. So does the scheduling system. Yet someone still has to check whether the warehouse has picked the order, whether the truck has room, and whether the customer has already paid for a particular delivery window. A simple request becomes several conversations between people looking at different screens.The business wants to offer a better service. Making that promise real requires changing how its software works.This is where I would begin a conversation about AI and software development. Business transformation now depends on software. A company can change its strategy in a meeting. Changing how the company actually operates usually reaches the systems that hold its information and carry out its decisions.“We aren’t a software company” describes what the company’s products. It says very little about what the company must be able to change.Years ago corporate owners would buy everyone a PC and Office on it and call their transformation done. Before that they might have invested in typewriters and filing cabinets, believing that equipping employees with the right tools was sufficient for transformation. Before that they were investing in light bulbs and electricity, thinking that illumination alone would drive progress. The pattern is clear: tools matter, but transformation occurs within the organization and the people who use the tools.So today, you can buy most of your software and still have this responsibility. Someone must understand how the purchased products fit together, which business rules they enforce, and what happens when a vendor changes something. A supplier can maintain its product. Your company remains responsible for the service built around it.Owning software, in this sense, means owning its continued fitness for the business. That requires proper maintenance. Security fixes are part of it. So are changing integrations, testing recovery, removing obsolete behavior, and adapting the system when the business makes a new promise. The obligation continues after the project budget closes.There is a competitive problem here too. Buying generic software can be an excellent decision. Common capabilities seldom justify inventing everything again. But as competitors buy the same capable products, it becomes harder to claim a differentiating advantage from the purchase itself. The distinction has to come from how the business works with those products, what it knows, and how well it serves people.I explored that moving baseline in the Red Queen problem in enterprise AI. An improvement can become an expectation once everyone can acquire it. Custom code offers no automatic escape. A well-run business using shared products can outperform one burdened with expensive custom systems. The useful question is which capabilities deserve to be distinctive, and how the company will keep them effective.That also gives us a better way to discuss development speed. An older method can remain appropriate. We should judge it by the service it supports and the cost of changing that service. When a needed improvement waits for another planning cycle while employees maintain a spreadsheet workaround, the delay has a business cost. Familiarity does not settle whether the method is still adequate.AI gives us reasons to reconsider that method. The opportunity reaches well beyond companies that sell software.The Software Development Method Needs Modern EngineeringYou might not be facing this level of competition yet, but in the coming years the pressure to handle massive volumes of changes efficiently will likely affect more organizations. Consider what happens at the far end of the scale.In its Oct. 13 account of redesigning source control, Anthropic said daily code changes in its main repository had risen from about 2,500 in May to more than 30,000 by September. This means that the company is making 2,500 - 30,000 changes to how its business runs every day. The company built a replacement for how it manages its software it around its increasingly agent-generated workload. Moving code into places where it could be inspected and tested had become an enormous infrastructure problem.Two days later, the Claude Code team described changing how it reviews code. Working in on a seperate track, its experts were reducing the human attention each change requires while watching incidents and reversions.These are accounts from a company with extraordinary access to its own models. Anthropic acknowledges that its requirements are unusual (for now). A distributor does not need to match its daily volume.The more useful observation is where effort went. Faster changes put pressure on the machinery for receiving, judging, combining, and releasing changes. The process of software development needed a process redesign and re-development of its own.In The IT Adaptive Factory, I described how delegating implementation moves responsibility into specifications, evaluation, infrastructure, and governance. These recent accounts show more of that responsibility taking a form that machines can use.AI is turning the software development process into an evolving software ecosystem. Teams express judgment through instructions, context, environments, checks, and limits. Those mechanisms need to be tested and maintained as the models and the work change.For a business that depends on software, which is almost every business these days, this becomes part of maintaining its ability to adapt to change. The application might be an ordinary billing service or scheduling tool. It need not contain AI. The change is in how people produce and care for it.Architecture and Engineering Knowledge Becomes an InputReturn to the delivery request. An agent could add a rescheduling button quickly. Whether that button should work after the truck has been loaded is a different question.An experienced colleague may know where that rule is documented. They may also know that the document is wrong and which person can explain the exception. Much of software development involves recovering this tribal knowledge that has accumulated since the last change took place before making the next change so that you can make the right change that won’t break things.That knowledge contains the very thing the business wants to preserve, a functioning business. A distributor might allow an exception because it understands a customer’s receiving hours or can combine nearby deliveries. A generic platform cannot infer which arrangements the company has promised to honor.An agent needs a way to gain that understanding. Otherwise it can implement a plausible generic process that quietly removes something the customers and the business values.Andreas Martin and Sandro Schwander’s September paper proposes a specification-driven development lifecycle using written specifications, repository instructions, and skills associated with different phases of work. The approach was applied in a university course and explored through student feedback. It is a useful process proposal with a more limited evidentiary basis than a demonstrated enterprise standard.Its practical premise matters. Agreements about the work become inputs an agent can consult while doing it. Someone must establish which agreements are authoritative and notice when they become wrong.There is a cost to carrying too much guidance. In September, Cursor described trimming its system prompt by roughly two-thirds, loading some tools only when needed, and improving context reuse. Its team tested the changes against production behavior. Instructions that helped earlier models were no longer always necessary.So the task includes currating relevant context, preserving the reasons behind important constraints, and retiring stale guidance. The instructions need an owner and evidence of their usefulness.A business rule buried in someone’s memory is difficult to maintain. Once its written down, it needs to be managed and maintained as an asset. Once its managed, it can be questioned. Connected to a test, it can be checked. The organization can then change its implementation while preserving the processes.The Workplace ExpandsHow do people bring that understanding into the work?The familiar picture puts a developer at a keyboard in a local copy of the application. That remains useful. Other ways of participating are becoming practical too.Addy Osmani’s guide to Claude Code cloud sessions demonstrates independent tasks running on separate machines. Each environment has its own files and processes. Isolation lets work proceed simultaneously, but one session cannot assume another session’s unfinished fix is available. Someone still needs to define the boundaries and the order for combining results.Simon Willison offers a smaller example. He built much of a Django feature through voice conversation while cooking dinner, following progress through a browser preview. He returned to the keyboard for detailed corrections and the remaining work before deployment. His account shows both the reach of the conversational interface and where typing remained more efficient.GitHub’s September guide to custom canvases describes an agent building a board, checklist, or other interface around a workflow. Both the person and the agent can update it.These examples suggest that the workspace must fit the assignment. A person might describe intent through conversation, inspect a working result, adjust a shared board, or investigate the code directly.For the distributor, use that flexibility to bring the dispatcher into the conversation earlier. Let the person who understands the route examine the proposed behavior while it is still cheap to correct. Their participation should produce a decision the development system can retain.A more convenient interface does not grant the agent authority to change a customer commitment. Nor does parallel execution resolve a disputed rule. Three agents working from the same unanswered question give us three implementations to reconsider.The business needs a way to settle the question and make the answer available to everyone doing the work.The Machinery Needs Its Own TestsOnce machines help translate business knowledge into software, we need evidence to show that it got everything correct and that the translation worked.A coding agent can satisfy the examples it sees without implementing the full requirement. A second agent can repeat the same assumption. Agreement between them may leave the original misunderstanding intact.The October Generative Test-Driven Development paper proposes holding a candidate implementation unchanged while a separate testing agent generates fresh inputs. A trusted evaluator checks the results. The method separates feedback used to improve the implementation from evidence used to accept it. The paper includes a limited experiment on a stateful key-value store, leaving substantial work before we can generalize its results.The enterprise implication is straightforward. Showing that the rescheduling button works, use to be sufficient, but now you need to know if the change is better then the previous behavior overall. We also need cases that challenge the rule, with an independent basis for deciding what should happen.We also need to take into account that the development machinery can fail in its own way. One change in the Claude Code account went through more than 50 rounds of automated review and repair overnight. The team limited rounds, narrowed subsequent reviews, and suppressed repeated findings. The review system needed correction too.In Dev, Test, and Prod Still Matter, I distinguished the deployed assembly from its authority, state, and supporting evidence. The machinery producing that assembly deserves the same attention. Changing an agent’s instructions or access can change its output and the consequences it can cause. Those changes belong in the record of what was evaluated.This is part of proper maintenance. The company needs to know whether its way of changing software continues to protect the service people depend on.Operational Maintenance Becomes a Standing AssignmentA successful launch begins a continuing obligation to keep the system operational and aligned with evolving business needs.The delivery service will encounter new customer arrangements and changes to other systems. Its dependencies will need updates. Some behavior will become unnecessary. Keeping yesterday’s implementation running may eventually preserve the wrong thing.That gives operations a direct role in business transformation. Each improvement becomes something the organization must keep useful, revise, or retire. A plan that funds the new capability and leaves its care to whoever has time is incomplete.In its September account of making claude.ai faster, Anthropic described a two-week performance effort organized around measured user journeys. Claude helped investigate bottlenecks, construct benchmarks, propose changes, and examine results after deployment. Engineers supplied direction, considered tradeoffs, and approved changes.The measurements required scrutiny too. The team checked that laboratory improvements corresponded to better user latency and discarded unsuitable benchmarks. A number an agent can improve is useful only when moving it helps the experience people actually have.This suggests a different shape for some operational work. A team can give an agent a continuing responsibility for a bounded problem, with measurements, limits, and a route back to the people responsible for the service. The investment in detecting a problem can then support future fixes and reveal when an improvement has been lost.At the distributor, operational work begins by measuring whether customers can complete a valid change and whether it reaches the warehouse and driver correctly. Page speed alone would miss most of the promise.Someone must remain responsible for questioning the target. A faster process can make the wrong decision sooner. A lower infrastructure bill can introduce an unacceptable delay. People need the authority to stop an assignment or revise its purpose.The business can delegate work while retaining accountability for the result. Buying the software and employing an agent both require that distinction.Cheaper Change Reopens Old DecisionsIf change becomes less expensive, some decisions about what to buy, build, or leave alone deserve another look.A small integration may once have cost too much to justify. A useful service variation may have been rejected because the standard product could not support it. Lower development costs could make either worth reconsidering.The estimate still has to cover the whole obligation.Osmani’s explanation of cost per task shows how repeated attempts, context, caching, and reasoning effort affect the cost of completed work. A cheaper interaction can produce a more expensive assignment when it creates another cycle of investigation and repair.In The Cost of a Finished Job, I argued for including human review, support, rework, and failure costs in the accepted outcome. That remains the useful boundary. For a build-or-buy decision, I would also include the cost of keeping the capability useful and eventually replacing it.The economics continue after the code runs. Willison argues for hard spending limits because agents make it easier to create systems that consume paid services. A notification received while someone sleeps does not stop the expenditure. Limits and stop behavior belong in the design of unattended work.There are more surprising possibilities. Developer Popcar’s October commentary on game decompilation points to AI-assisted efforts to recover and port older games. The examples raise questions about preservation and the cost of reconstructing software with overwhelming amounts of technical debt.An old application contains behavior people rely on, sometimes for reasons its documentation no longer explains. AI may help recover that understanding. The company still has to decide what to preserve and prove that the replacement does so.There is a useful competitive question underneath these decisions. If implementing a familiar feature becomes easier for us, it may become easier for competitors too. I would be cautious about treating possession of the code as the lasting advantage. The ability to understand a customer need, change the service safely, and learn from the result is harder to do than to customize the code or modernize the process.Use shared products where they serve the business well. Put deliberate engineering effort into the capabilities that matter to how the business competes. Budget for their continued care.The Team Has to Keep LearningThis argument depends on human judgment. That judgment needs somewhere to grow. Which means that the team must humbly accept that what they know today is incomplete, inaccurate, and incorrect. Otherwise that ongoing learning opportunity will never materalize.Anthropic’s October study of employment inside the company describes employees spending more effort managing agents and hiring managers emphasizing autonomy and judgment. It also documents a declining share of junior technical hiring. This is one company undergoing rapid growth and intensive AI adoption. Its experience gives us a case to examine, with clear limits on conclusions about employment elsewhere.The apprenticeship question is: How will people gain the necessary understanding of the system and its boundaries when the AI generates implementations before they have explored the problem themselves? Small defects taught people where system boundaries were. Routine features exposed younger developers to the tribal knowledge about the system. Explaining a change to a colleague revealed gaps in that understanding.How will people acquire that understanding when an implementation arrives before they have worked through the problem?The solution to this is to use development methodologies that already solve for this kind of learning. Look at Mob programming, where the team rotates through roles and everyone gets exposure to the problem-solving process. This ensures that knowledge is shared and that learning is embedded in the workflow. Look at XP (Extreme Programming), which emphasizes pair programming, collective code ownership, and continuous feedback. These practices create structured opportunities for learning and knowledge transfer within the team.If you adopt these methodologies, you will provide the newer engineers the opportunities to explain generated systems, investigate failures, write independent scenarios, and defend architectural choices. They will also get to work directly with the code while having someone guide them. You are trying to pair them with people who can distinguish a convincing explanation from an adequate one.This takes an active decision to prioritize learning over immediate being busy. A person learning to diagnose an agent’s failure while the whole mob watches and teach them the process may seem like even a slower immediate cycle. However, this is a deliberate and sound investment in the team’s ability to maintain the service next year, and grow the culture of the team past the current generation of engineers.Experienced people need protection too. A senior engineer can become the destination for every unresolved question. Adding agents can overload that person even as a dashboard reports more and more completed work. Having a team of people who that senior engineer can work with to share the load and distribute knowledge helps prevent burnout and ensures that critical understanding is not concentrated in a single individual.The same problem reaches the project manager who understands unusual deliveries. Turning their knowledge into instructions should make it available to the team and help successors learn it. Otherwise the business risks depending on a person and a growing collection of rules that nobody else understands.In Beyond the Mirror, I argued that people need a meaningful part in shaping the work and sharing in its gains. Here that means influence over the development machinery, time to understand its failures, and a sustainable limit on the attention it demands.A business that needs software must retain a full team that has the ability to know how that software works. Maintaining that ability includes developing the people who will exercise it.I should also point out, that this is the responsibility of the whole team. Everyone’s role includes contributing to the shared understanding, mentoring newer members, and ensuring that critical knowledge is not siloed in a single individual. This means that everyone learns from everyone else. This isn’t a call for more specializatoin, but for a culture of collective cross-pollination and knowledge sharing.Start With One Recurring CorrectionMuch of this rests on going back to achievements from earlier eras of software development. Written requirements, automated tests, paired programming, team accountability, isolated environments, and feedback from production remain useful foundations. Their age tells us little about whether a particular practice still serves the work.What is changing is the division of responsibility. We can increasingly give a system an objective and let it investigate, choose intermediate actions, and propose an implementation. Its behavior depends partly on instructions and context that can produce different results across runs. The method around it needs continuing evaluation.I would begin with one recurring class of change in a business capability people understand. It might involve a purchased platform and a small integration. It might involve an application the company has maintained for years.Agree on the improvement customers or employees should experience. Establish what an acceptable result looks like and what today’s method costs in elapsed time, money, attention, and repair. Include the work people do while waiting for the software to catch up.Then find a correction an experienced person keeps making. Decide whether it belongs in a specification, available context, an executable check, or a decision that should continue to require a person. Try the revised method on representative work, including awkward cases. Keep failed attempts in the account.Give someone responsibility for maintaining the instruction or check. Make it possible to revise or remove it. See whether the next change requires less rediscovery and repair, and whether the resulting service actually improves.That is a practical place to begin, regardless of whether software appears on the company’s invoices.For the customer changing tomorrow’s delivery, the test is simple: Does the company keep its new promise?A competitor can buy the same scheduling product. The difference can come from how well your business understands the delivery and how reliably it turns that understanding into service. Maintaining that ability is part of running the business. The responsibility lasts as long as the promise does.", "content_html": "Business transformation depends on software we can keep changing. AI is changing how we build and maintain that capability.
Suppose a distributor wants to let customers change tomorrow’s delivery without making a phone call.
The customer portal already exists. So does the scheduling system. Yet someone still has to check whether the warehouse has picked the order, whether the truck has room, and whether the customer has already paid for a particular delivery window. A simple request becomes several conversations between people looking at different screens.
The business wants to offer a better service. Making that promise real requires changing how its software works.
This is where I would begin a conversation about AI and software development. Business transformation now depends on software. A company can change its strategy in a meeting. Changing how the company actually operates usually reaches the systems that hold its information and carry out its decisions.
“We aren’t a software company” describes what the company’s products. It says very little about what the company must be able to change.
Years ago corporate owners would buy everyone a PC and Office on it and call their transformation done. Before that they might have invested in typewriters and filing cabinets, believing that equipping employees with the right tools was sufficient for transformation. Before that they were investing in light bulbs and electricity, thinking that illumination alone would drive progress. The pattern is clear: tools matter, but transformation occurs within the organization and the people who use the tools.
So today, you can buy most of your software and still have this responsibility. Someone must understand how the purchased products fit together, which business rules they enforce, and what happens when a vendor changes something. A supplier can maintain its product. Your company remains responsible for the service built around it.
Owning software, in this sense, means owning its continued fitness for the business. That requires proper maintenance. Security fixes are part of it. So are changing integrations, testing recovery, removing obsolete behavior, and adapting the system when the business makes a new promise. The obligation continues after the project budget closes.
There is a competitive problem here too. Buying generic software can be an excellent decision. Common capabilities seldom justify inventing everything again. But as competitors buy the same capable products, it becomes harder to claim a differentiating advantage from the purchase itself. The distinction has to come from how the business works with those products, what it knows, and how well it serves people.
I explored that moving baseline in the Red Queen problem in enterprise AI. An improvement can become an expectation once everyone can acquire it. Custom code offers no automatic escape. A well-run business using shared products can outperform one burdened with expensive custom systems. The useful question is which capabilities deserve to be distinctive, and how the company will keep them effective.
That also gives us a better way to discuss development speed. An older method can remain appropriate. We should judge it by the service it supports and the cost of changing that service. When a needed improvement waits for another planning cycle while employees maintain a spreadsheet workaround, the delay has a business cost. Familiarity does not settle whether the method is still adequate.
AI gives us reasons to reconsider that method. The opportunity reaches well beyond companies that sell software.
You might not be facing this level of competition yet, but in the coming years the pressure to handle massive volumes of changes efficiently will likely affect more organizations. Consider what happens at the far end of the scale.
In its Oct. 13 account of redesigning source control, Anthropic said daily code changes in its main repository had risen from about 2,500 in May to more than 30,000 by September. This means that the company is making 2,500 - 30,000 changes to how its business runs every day. The company built a replacement for how it manages its software it around its increasingly agent-generated workload. Moving code into places where it could be inspected and tested had become an enormous infrastructure problem.
Two days later, the Claude Code team described changing how it reviews code. Working in on a seperate track, its experts were reducing the human attention each change requires while watching incidents and reversions.
These are accounts from a company with extraordinary access to its own models. Anthropic acknowledges that its requirements are unusual (for now). A distributor does not need to match its daily volume.
The more useful observation is where effort went. Faster changes put pressure on the machinery for receiving, judging, combining, and releasing changes. The process of software development needed a process redesign and re-development of its own.
In The IT Adaptive Factory, I described how delegating implementation moves responsibility into specifications, evaluation, infrastructure, and governance. These recent accounts show more of that responsibility taking a form that machines can use.
AI is turning the software development process into an evolving software ecosystem. Teams express judgment through instructions, context, environments, checks, and limits. Those mechanisms need to be tested and maintained as the models and the work change.
For a business that depends on software, which is almost every business these days, this becomes part of maintaining its ability to adapt to change. The application might be an ordinary billing service or scheduling tool. It need not contain AI. The change is in how people produce and care for it.
Return to the delivery request. An agent could add a rescheduling button quickly. Whether that button should work after the truck has been loaded is a different question.
An experienced colleague may know where that rule is documented. They may also know that the document is wrong and which person can explain the exception. Much of software development involves recovering this tribal knowledge that has accumulated since the last change took place before making the next change so that you can make the right change that won’t break things.
That knowledge contains the very thing the business wants to preserve, a functioning business. A distributor might allow an exception because it understands a customer’s receiving hours or can combine nearby deliveries. A generic platform cannot infer which arrangements the company has promised to honor.
An agent needs a way to gain that understanding. Otherwise it can implement a plausible generic process that quietly removes something the customers and the business values.
Andreas Martin and Sandro Schwander’s September paper proposes a specification-driven development lifecycle using written specifications, repository instructions, and skills associated with different phases of work. The approach was applied in a university course and explored through student feedback. It is a useful process proposal with a more limited evidentiary basis than a demonstrated enterprise standard.
Its practical premise matters. Agreements about the work become inputs an agent can consult while doing it. Someone must establish which agreements are authoritative and notice when they become wrong.
There is a cost to carrying too much guidance. In September, Cursor described trimming its system prompt by roughly two-thirds, loading some tools only when needed, and improving context reuse. Its team tested the changes against production behavior. Instructions that helped earlier models were no longer always necessary.
So the task includes currating relevant context, preserving the reasons behind important constraints, and retiring stale guidance. The instructions need an owner and evidence of their usefulness.
A business rule buried in someone’s memory is difficult to maintain. Once its written down, it needs to be managed and maintained as an asset. Once its managed, it can be questioned. Connected to a test, it can be checked. The organization can then change its implementation while preserving the processes.
How do people bring that understanding into the work?
The familiar picture puts a developer at a keyboard in a local copy of the application. That remains useful. Other ways of participating are becoming practical too.
Addy Osmani’s guide to Claude Code cloud sessions demonstrates independent tasks running on separate machines. Each environment has its own files and processes. Isolation lets work proceed simultaneously, but one session cannot assume another session’s unfinished fix is available. Someone still needs to define the boundaries and the order for combining results.
Simon Willison offers a smaller example. He built much of a Django feature through voice conversation while cooking dinner, following progress through a browser preview. He returned to the keyboard for detailed corrections and the remaining work before deployment. His account shows both the reach of the conversational interface and where typing remained more efficient.
GitHub’s September guide to custom canvases describes an agent building a board, checklist, or other interface around a workflow. Both the person and the agent can update it.
These examples suggest that the workspace must fit the assignment. A person might describe intent through conversation, inspect a working result, adjust a shared board, or investigate the code directly.
For the distributor, use that flexibility to bring the dispatcher into the conversation earlier. Let the person who understands the route examine the proposed behavior while it is still cheap to correct. Their participation should produce a decision the development system can retain.
A more convenient interface does not grant the agent authority to change a customer commitment. Nor does parallel execution resolve a disputed rule. Three agents working from the same unanswered question give us three implementations to reconsider.
The business needs a way to settle the question and make the answer available to everyone doing the work.
Once machines help translate business knowledge into software, we need evidence to show that it got everything correct and that the translation worked.
A coding agent can satisfy the examples it sees without implementing the full requirement. A second agent can repeat the same assumption. Agreement between them may leave the original misunderstanding intact.
The October Generative Test-Driven Development paper proposes holding a candidate implementation unchanged while a separate testing agent generates fresh inputs. A trusted evaluator checks the results. The method separates feedback used to improve the implementation from evidence used to accept it. The paper includes a limited experiment on a stateful key-value store, leaving substantial work before we can generalize its results.
The enterprise implication is straightforward. Showing that the rescheduling button works, use to be sufficient, but now you need to know if the change is better then the previous behavior overall. We also need cases that challenge the rule, with an independent basis for deciding what should happen.
We also need to take into account that the development machinery can fail in its own way. One change in the Claude Code account went through more than 50 rounds of automated review and repair overnight. The team limited rounds, narrowed subsequent reviews, and suppressed repeated findings. The review system needed correction too.
In Dev, Test, and Prod Still Matter, I distinguished the deployed assembly from its authority, state, and supporting evidence. The machinery producing that assembly deserves the same attention. Changing an agent’s instructions or access can change its output and the consequences it can cause. Those changes belong in the record of what was evaluated.
This is part of proper maintenance. The company needs to know whether its way of changing software continues to protect the service people depend on.
A successful launch begins a continuing obligation to keep the system operational and aligned with evolving business needs.
The delivery service will encounter new customer arrangements and changes to other systems. Its dependencies will need updates. Some behavior will become unnecessary. Keeping yesterday’s implementation running may eventually preserve the wrong thing.
That gives operations a direct role in business transformation. Each improvement becomes something the organization must keep useful, revise, or retire. A plan that funds the new capability and leaves its care to whoever has time is incomplete.
In its September account of making claude.ai faster, Anthropic described a two-week performance effort organized around measured user journeys. Claude helped investigate bottlenecks, construct benchmarks, propose changes, and examine results after deployment. Engineers supplied direction, considered tradeoffs, and approved changes.
The measurements required scrutiny too. The team checked that laboratory improvements corresponded to better user latency and discarded unsuitable benchmarks. A number an agent can improve is useful only when moving it helps the experience people actually have.
This suggests a different shape for some operational work. A team can give an agent a continuing responsibility for a bounded problem, with measurements, limits, and a route back to the people responsible for the service. The investment in detecting a problem can then support future fixes and reveal when an improvement has been lost.
At the distributor, operational work begins by measuring whether customers can complete a valid change and whether it reaches the warehouse and driver correctly. Page speed alone would miss most of the promise.
Someone must remain responsible for questioning the target. A faster process can make the wrong decision sooner. A lower infrastructure bill can introduce an unacceptable delay. People need the authority to stop an assignment or revise its purpose.
The business can delegate work while retaining accountability for the result. Buying the software and employing an agent both require that distinction.
If change becomes less expensive, some decisions about what to buy, build, or leave alone deserve another look.
A small integration may once have cost too much to justify. A useful service variation may have been rejected because the standard product could not support it. Lower development costs could make either worth reconsidering.
The estimate still has to cover the whole obligation.
Osmani’s explanation of cost per task shows how repeated attempts, context, caching, and reasoning effort affect the cost of completed work. A cheaper interaction can produce a more expensive assignment when it creates another cycle of investigation and repair.
In The Cost of a Finished Job, I argued for including human review, support, rework, and failure costs in the accepted outcome. That remains the useful boundary. For a build-or-buy decision, I would also include the cost of keeping the capability useful and eventually replacing it.
The economics continue after the code runs. Willison argues for hard spending limits because agents make it easier to create systems that consume paid services. A notification received while someone sleeps does not stop the expenditure. Limits and stop behavior belong in the design of unattended work.
There are more surprising possibilities. Developer Popcar’s October commentary on game decompilation points to AI-assisted efforts to recover and port older games. The examples raise questions about preservation and the cost of reconstructing software with overwhelming amounts of technical debt.
An old application contains behavior people rely on, sometimes for reasons its documentation no longer explains. AI may help recover that understanding. The company still has to decide what to preserve and prove that the replacement does so.
There is a useful competitive question underneath these decisions. If implementing a familiar feature becomes easier for us, it may become easier for competitors too. I would be cautious about treating possession of the code as the lasting advantage. The ability to understand a customer need, change the service safely, and learn from the result is harder to do than to customize the code or modernize the process.
Use shared products where they serve the business well. Put deliberate engineering effort into the capabilities that matter to how the business competes. Budget for their continued care.
This argument depends on human judgment. That judgment needs somewhere to grow. Which means that the team must humbly accept that what they know today is incomplete, inaccurate, and incorrect. Otherwise that ongoing learning opportunity will never materalize.
Anthropic’s October study of employment inside the company describes employees spending more effort managing agents and hiring managers emphasizing autonomy and judgment. It also documents a declining share of junior technical hiring. This is one company undergoing rapid growth and intensive AI adoption. Its experience gives us a case to examine, with clear limits on conclusions about employment elsewhere.
The apprenticeship question is: How will people gain the necessary understanding of the system and its boundaries when the AI generates implementations before they have explored the problem themselves? Small defects taught people where system boundaries were. Routine features exposed younger developers to the tribal knowledge about the system. Explaining a change to a colleague revealed gaps in that understanding.
How will people acquire that understanding when an implementation arrives before they have worked through the problem?
The solution to this is to use development methodologies that already solve for this kind of learning. Look at Mob programming, where the team rotates through roles and everyone gets exposure to the problem-solving process. This ensures that knowledge is shared and that learning is embedded in the workflow. Look at XP (Extreme Programming), which emphasizes pair programming, collective code ownership, and continuous feedback. These practices create structured opportunities for learning and knowledge transfer within the team.
If you adopt these methodologies, you will provide the newer engineers the opportunities to explain generated systems, investigate failures, write independent scenarios, and defend architectural choices. They will also get to work directly with the code while having someone guide them. You are trying to pair them with people who can distinguish a convincing explanation from an adequate one.
This takes an active decision to prioritize learning over immediate being busy. A person learning to diagnose an agent’s failure while the whole mob watches and teach them the process may seem like even a slower immediate cycle. However, this is a deliberate and sound investment in the team’s ability to maintain the service next year, and grow the culture of the team past the current generation of engineers.
Experienced people need protection too. A senior engineer can become the destination for every unresolved question. Adding agents can overload that person even as a dashboard reports more and more completed work. Having a team of people who that senior engineer can work with to share the load and distribute knowledge helps prevent burnout and ensures that critical understanding is not concentrated in a single individual.
The same problem reaches the project manager who understands unusual deliveries. Turning their knowledge into instructions should make it available to the team and help successors learn it. Otherwise the business risks depending on a person and a growing collection of rules that nobody else understands.
In Beyond the Mirror, I argued that people need a meaningful part in shaping the work and sharing in its gains. Here that means influence over the development machinery, time to understand its failures, and a sustainable limit on the attention it demands.
A business that needs software must retain a full team that has the ability to know how that software works. Maintaining that ability includes developing the people who will exercise it.
I should also point out, that this is the responsibility of the whole team. Everyone’s role includes contributing to the shared understanding, mentoring newer members, and ensuring that critical knowledge is not siloed in a single individual. This means that everyone learns from everyone else. This isn’t a call for more specializatoin, but for a culture of collective cross-pollination and knowledge sharing.
Much of this rests on going back to achievements from earlier eras of software development. Written requirements, automated tests, paired programming, team accountability, isolated environments, and feedback from production remain useful foundations. Their age tells us little about whether a particular practice still serves the work.
What is changing is the division of responsibility. We can increasingly give a system an objective and let it investigate, choose intermediate actions, and propose an implementation. Its behavior depends partly on instructions and context that can produce different results across runs. The method around it needs continuing evaluation.
I would begin with one recurring class of change in a business capability people understand. It might involve a purchased platform and a small integration. It might involve an application the company has maintained for years.
Agree on the improvement customers or employees should experience. Establish what an acceptable result looks like and what today’s method costs in elapsed time, money, attention, and repair. Include the work people do while waiting for the software to catch up.
Then find a correction an experienced person keeps making. Decide whether it belongs in a specification, available context, an executable check, or a decision that should continue to require a person. Try the revised method on representative work, including awkward cases. Keep failed attempts in the account.
Give someone responsibility for maintaining the instruction or check. Make it possible to revise or remove it. See whether the next change requires less rediscovery and repair, and whether the resulting service actually improves.
That is a practical place to begin, regardless of whether software appears on the company’s invoices.
For the customer changing tomorrow’s delivery, the test is simple: Does the company keep its new promise?
A competitor can buy the same scheduling product. The difference can come from how well your business understands the delivery and how reliably it turns that understanding into service. Maintaining that ability is part of running the business. The responsibility lasts as long as the promise does.
", "url": "https://tedt.org/The-Business-Transformation-Has-Become-a-Software-Process/", "image": "/img/2026-10/Software-Foundation.webp", "tags": ["business transformation","software development","AI coding agents","software maintenance","specification-driven development","software testing","engineering leadership","team learning"], "date_published": "2026-10-17T00:00:00-07:00", "date_modified": "2026-10-17T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/The-Last-Maintenance-Window/", "title": "The Last Maintenance Window", "summary": "A cooperative map-drawing game about patching servers, rebuilding IT systems, and keeping essential services running before general intelligence arrives.", "content_text": "The Last Maintenance WindowA cooperative map-drawing game about patching servers, rebuilding IT systems, and keeping essential services running before general intelligence arrives.Revised playtest edition · Version 0.2 · October 11, 2026You collectively portray the people responsible for an organization’s technology. Over a fictional year, you discover what exists, repair what you can, introduce useful capabilities, and decide how much authority to delegate to AI. Your map records both the infrastructure and the people holding it together.This is an unofficial, self-contained game inspired by Avery Alder’s The Quiet Year. The setting, event prompts, verification procedures, and Arrival scenarios here are original. At a glance Details Players 2–5. For a first session, try 3–4. Full game Allow roughly 3–4 hours for setup, play, and the ending; a reflective group may need longer. Short game Allow roughly 2 hours for setup, play, and the ending. A prepared group may finish in 90 minutes. Optional workshop debrief Add 15–20 minutes to either version. Technical knowledge Optional. Ordinary descriptions of needs, actions, and observations are sufficient. Status A playable draft. Session lengths and incentives still need live playtesting. Quick navigation: Setup · A week · Actions · Short game and facilitation · Event deck · Arrival · Starter scenario · Worked examples · Table reference1. The premiseRead aloud: At 02:13, the backup console turns green. Nobody has tried restoring the payroll system since the people who built it left. In another building, a server labeled TEMP has been running for eleven years. A junior engineer has used an AI assistant to understand its oldest program. For the first time, replacing it looks possible. There is money for some improvements. There are people who care. There are also customers who need tomorrow’s service, managers who promised next month’s launch, and an on-call team that would like one uninterrupted weekend. Outside the organization, AI systems are becoming capable of longer, more independent work. They can help us find defects and make repairs. They can also give strangers new capabilities and act on permissions we barely remember granting. By winter, broadly capable general intelligence will become available. We do not know the week, who will control it, or which of our assumptions will survive its arrival. The next maintenance window opens tonight. What will we do with it?The Arrival and its timing are fictional premises that give the game its deadline. Your organization tries to preserve essential services while building systems whose behavior people can observe, whose authority they can limit, and whose failures they can recover from.There is no numerical winner. The story ends by showing what the organization can reasonably depend on, what remains uncertain, and who lives with the consequences.Your role as playersPlayers collectively portray the organization. You do not own a character or department. On different turns you may speak for an operator, a customer, a manager, or someone who disagrees with a decision you previously supported.When you choose a card option, you help author the year. Choose a situation that brings an interesting unresolved person, service, or dependency into focus. Include opportunities, relief, mistakes, and difficult choices. The weekly action then determines what the organization does with its limited attention.Help one another make contributions concrete. Technical experience is useful when it helps someone express an idea; it does not give a player authority to reject a contribution because it lacks professional terminology. No one needs to name actual products, commands, or configuration settings.2. Prepare the tableSupplies and responsibilitiesYou need a large sheet of paper or shared whiteboard, pens, a standard 52-card deck without jokers, three six-sided dice, about twenty tokens, and index cards or sticky notes. If you run out of concern tokens, use labeled marks or slips of paper.One person teaches the rules and watches the time. Choose a first steward, then rotate that role clockwise each week. Another player can record the steward’s decisions and draw the map; rotate this help as useful.Decide whether to use the full or short calendar. Also choose the Arrival method now: choose a scenario together for its story interest, or roll for an uncertain scenario. Keep that choice through the session. The six scenarios are in section 9.For a quick start, use North Valley Electric in section 10. Otherwise create an organization using the steps below.Choose the organization and its purposeInvent its name and purpose. A utility, hospital, university, manufacturer, or municipal service works well.Choose exactly three essential services, describing the human outcome each provides. Keep them visible throughout play. Example service Human outcome Field repair coordination Crews receive usable information and can coordinate their work. Outage communication Customers can report problems and get meaningful information. Payroll and supplier payments Employees and suppliers receive the money they are owed. Agree on one commitment the organization will try to honor. Examples include preserving emergency communication, maintaining a human route to appeal consequential automated decisions, or giving staff predictable rest. Write it beside the services. You will return to it at phase transitions and at the Arrival.Establish what the three services ordinarily do today, including any existing degradation. Ordinary operation is a starting fact. Working today does not establish a special recovery, containment, or fallback capability.Draw the starting mapDraw six to ten connected systems or places. Include aging servers, identity and administrative access, business applications and data, software delivery, backups, an external provider, and somewhere people work or request help. Add any AI tool already in use. One drawing may combine closely related items.Label relationships so everyone can follow them. Write phrases such as “sends payment records to,” “can administer,” or “needs this to sign in.” A data flow does not automatically grant administrative access.Connect each essential service to its dependencies. Add at least one unclear relationship and give an old machine a nickname. Each player adds a person or group and something they need.Use these marks: Mark Meaning Box or drawing An existing system, service, team, vendor, or place. Labeled line or arrow An established access, data, dependency, or human handoff relationship. PLANNED beside a shape or line A proposed change. It provides no existing capability. Dotted line or ? Something important is unknown. State the question. ! A specific unresolved exposure, failure, or unmet need. Check mark and evidence number, such as E1 A demonstrated claim with a recorded observation and scope. Concern token with a short label Someone’s unresolved concern, obligation, or burden. Crossed-out shape or line Something retired or removed. Keep it visible as history. Whenever a card asks you to draw a boundary or system that would help, label it PLANNED. Starting a project does not implement its promised change. Implementation and evidence are recorded separately.Existing safeguards at setup may be drawn as facts, with uncertain behavior marked ?. Do not add evidence numbers merely because a safeguard sounds reassuring. A Verify action can establish a new demonstration during play.Name strengths and shortagesChoose two strengths and two shortages. Possibilities include experienced operators, spare hardware, money, vendor support, documentation, test environments, maintenance access, executive trust, and rested staff.These are continuing facts in the story. When work needs something scarce, name a concrete accommodation: narrow the work, borrow help and incur an obligation, or postpone another commitment. Attach the cost to an established person, team, service, or promise.“We borrow help” is incomplete. “Mara covers dispatch, so her documentation work waits” gives the story something to revisit. Section 6 explains how resources and concerns change.3. Arrange the yearSeparate the cards by suit and shuffle each suit independently. Draw through the suits in this order: Suit Phase Emphasis Hearts Discovery What exists, who owns it, and who depends on it. Diamonds Repair Patching, replacement, simplification, and their consequences. Clubs Acceleration Useful AI, faster changes, and expanding delegated authority. Spades The Threshold Urgent choices under increasing uncertainty. Each ordinary card represents one week. Keep the King of Spades shuffled among the spades. Drawing it triggers the Arrival immediately, before an ordinary event, project progress, or action.The full calendar contains 39–51 ordinary weeks, followed by the Arrival draw. The short calendar contains 21–27 ordinary weeks; prepare it using section 7.Between phasesAfter completing hearts, diamonds, or clubs, pause briefly. Name one thing the organization gained and revisit one existing burden or obligation. Ask whether a strength, shortage, or the initial commitment has changed meaning. Update a label only when established events or actions justify the change.This reflection grants no project progress, extra action, agreement, repair, or verification. Carry unresolved matters into the next phase. Do not take a phase pause before resolving the King of Spades.4. Play one weekThe steward resolves the chosen event and action. Other players may clarify established facts, answer an invitation from the steward, or contribute as the action specifies. Save extended persuasion and negotiation for Council.Follow this order: Draw and resolve the event. If it is the King of Spades, freeze play and go directly to the Arrival. Otherwise read the card’s shared instruction, if any, and choose Option 1 OR Option 2. Resolve the chosen situation, then apply the shared instruction once. The unchosen situation does not happen. Update the map. Progress existing projects. Consider projects that were RUNNING or BLOCKED before this week’s card was drawn. Each one that is now RUNNING and is not paused loses one week from its die. At zero, remove the die and mark it READY. Update the map with the change implemented in its recorded scope and environment. Take exactly one action: Survey, Build, Verify, or Council. Record the consequences. Keep new findings, obligations, evidence, and unresolved questions visible. Clear one-week pause marks and pass stewardship clockwise.A newly started project never progresses in its creation week. An event that clears an existing project’s blocker can allow that project to progress in step 2. A blocker cleared during the later action allows progress from the next week. A project returned to work by Verify also waits until the next week for its first reduction.A pause skips only the specified week’s progress. A block lasts until a named missing prerequisite changes. Neither creates extra progress later.If a shared pause instruction follows an event that already BLOCKED a project that was RUNNING at the draw, that project satisfies the pause instruction. Do not pause a second project just because the affected project is now BLOCKED. Keep its actual prerequisite block until the prerequisite returns.What the event can establishEvents establish the facts and consequences requested by the selected prompt. A discovery can supply information without Survey, and an explicit event can change a relationship. Discussing a proposed repair does not implement it. Naming who might agree to an offer does not automatically secure their agreement. Part of play Its authority Event Establish the facts and consequences specifically requested by its chosen prompt. Survey Investigate an unresolved question selected by the steward, beyond simply answering the event. Build Start bounded implementation using credible resources and agreements, or cancel one project. Verify Establish what one declared test target demonstrates. Council Hear affected perspectives and establish a decision, obligation, or acknowledged disagreement. Only explicit card instructions change mechanics beyond the normal rules. Newly established facts can still trigger normal rules: a genuinely missing prerequisite blocks work even if the card does not use the word “block.” A concern token by itself is not such a prerequisite.Reuse people and systems already on the map when they fit. Add something new when it gives the story a useful connection or contrast. Even a conversational event should leave a short, durable record: a changed relationship, an offer, a promise, an observation, or a question.Preserve history and allow changeAn event cannot erase an established observation or pretend that a demonstrated result never happened. It can change the circumstances afterward. A new model, altered permissions, a departed colleague, or different demand may put an earlier claim in doubt.Name what changed, retain the old evidence, and mark the new uncertainty. Preserve any parts of the earlier claim that still apply. If an event truly contradicts the map without introducing a credible change, adapt it to another relevant part of the organization or treat it as a reported warning.If one option does not fit, choose the other. If neither fits, adapt one to an established part of the organization while preserving its subject. If no credible local version exists, treat it as a report from elsewhere and record the question it raises; that report creates no local capability or failure. Any shared instruction still applies, and a shared effect with no eligible target does nothing. Adaptation cannot grant free implementation or evidence.5. The four actionsSurveyInvestigate one unresolved question and establish a specific finding. Choose the question yourself; it need not be the subject of this week’s card.You might locate a hidden server, identify an owner, trace an access route, discover usable equipment, hear a user’s need, or inspect existing records. Add the finding to the map and distinguish what is known from what remains uncertain. The supposedly retired database still supplies the dispatch schedule. The service owner knows the report, but nobody has mapped how it reaches the workroom.Survey establishes information. It cannot install a control, repair a system, settle an established refusal, or create a new numbered demonstration. Inspecting a record can reveal what it says; conducting a new test of a capability is Verify.BuildUse Build to start one project, or to cancel one project. These are separate uses of the action.The organization has three project slots. RUNNING, BLOCKED, and READY projects each occupy one slot.Start a projectStart in an empty slot. Projects can patch servers, replace applications, change access, prepare a recovery exercise, improve operating practices, establish a fallback, or retire a system.Record the following before assigning a countdown: Field Example Scope The two externally reachable file-transfer servers. Accountable owner The application operations team, in the fiction. Intended change Install the supported update and preserve the daily transfer. Implementation environment The two live servers during their agreed maintenance window. Human cost and accommodations Users accept a brief interruption; Mara covers the window and postpones documentation. Prerequisites The update is available, access is authorized, and the maintenance agreement exists. Acceptance condition and test Confirm the installed version, complete a representative transfer, and demonstrate the agreed recovery step. The accountable owner is a fictional person or team. Any player may act on any project.Describe work at the map’s level of detail. “Former staff cannot sign in, and current staff can still complete payroll” is an adequate acceptance condition. Name the observation that would support it; product names and configuration details are unnecessary.After about one minute of discussion, the steward chooses a duration: Scope Full game Short game Small, bounded change 2 weeks 1 week Change across a few dependencies or teams 4 weeks 2 weeks Difficult rebuild or major operating change 6 weeks 3 weeks These are fictional scheduling categories. Split broad promises into bounded projects. “Make the organization secure” is too broad. State whether implementation happens in a trial environment, a limited service, or live operation; that choice constrains later claims.An undisputed owner or available resource can be named during Build. Build cannot silently settle an established ownership dispute, invent consent previously refused, or remove a known shortage. Resolve an established disputed agreement through Council, or narrow the project so that agreement is unnecessary. Credible prerequisite implementation can be included within the scope, but automatic project progress cannot settle disputed consent.A project may begin BLOCKED if a necessary external prerequisite is still unavailable. Record its countdown and blocker, but do not reduce the die while it is blocked. Work that can genuinely proceed should be scoped separately if the group wants it to progress.Project states State Meaning RUNNING Implementation or rework can proceed; reduce the countdown during eligible progress steps. BLOCKED Implementation or rework waits for a named prerequisite; retain its remaining countdown. READY The intended change has been implemented in the recorded environment; its acceptance claim still needs verification. No countdown remains. When a prerequisite becomes available, return the project to RUNNING. A project does not unblock simply because time passes, a token is removed, or someone promises to investigate.When implementation reaches zero, update PLANNED marks for the work actually completed and mark the project READY. A READY change may already affect live service if its recorded environment is live. It has no demonstrated acceptance claim merely because it exists.Cancel a projectCancel any one project occupying a slot, including READY work. Cancellation uses the whole Build action. It does not also start a replacement.Free the slot, record why the organization stops pursuing the project, and name what remains stranded. Preserve any changes already established, including a READY implementation, with their uncertainties and consequences. Starting or canceling work grants no additional implementation. Canceling a deployed change does not roll it back; actual removal or repair needs appropriate work.VerifyChoose one declared target: One READY project; or One existing capability whose test arrangements already exist, with a written, bounded acceptance condition.An existing capability does not need a new implementation project merely to be tested. If it needs substantial preparation—new equipment, access, data, procedures, or agreement—arrange that through Build or Council first. Existing operation and existing records alone are not a new demonstration.Describe the acceptance test being performed in the fiction. The next player clockwise offers one relevant question, limitation, or challenge. Ground it in the map, the stated test, or an observation arising from that test. Testing may reveal a relevant new problem; nobody should invent an unrelated disaster simply to force failure.The steward resolves the scene, respecting established facts and the written condition. Resolve one outcome: Outcome What happens Pass The observation meets the acceptance condition. Record numbered evidence describing the result, scope, and relevant conditions. If the declared target was a READY project, free that one slot. Gap on a READY project Name the missing work and return the project to 2 weeks in the full game, or 1 in the short game. It keeps its slot. If a necessary prerequisite is unavailable, mark it BLOCKED with that countdown. Otherwise mark it RUNNING. Gap on an existing capability Record the finding and affected claim. No project starts automatically. Later Build or Council actions can arrange the needed change, and a later Verify can retest it. One Verify action frees at most the declared project’s slot. Choosing an existing capability does not silently complete other READY projects.A limitation outside the acceptance condition narrows the evidence note. An unresolved issue necessary to meet the condition prevents a Pass. Recording uncertainty does not also establish the uncertain behavior as demonstrated. If the only supported claim is narrower than the project’s agreed condition, record that partial observation and a Gap; do not quietly rewrite the condition after the test.If a READY project lacks necessary test arrangements, keep it READY while those arrangements are obtained. Alternatively, use its Verify action to record a preparation Gap and return that project to the rework process above. State that the test could not yet run. This permits test preparation within the occupied slot without pretending a test succeeded or forcing a new project slot.Rework must remain credible in the scope. A newly discovered major dependency may require a separate project; the two-week or one-week rework countdown cannot implement an entire missing platform for free.Example evidence: E3: Restored payroll using independent recovery access in the agreed exercise. The observation covers one representative environment and the recorded version; it does not establish recovery under every future condition.Remove only the exposures the observation resolves. A verified patch can coexist with a shared-credential problem. Keep historical evidence when later conditions change, and mark which claims now require reconsideration.CouncilChoose one disputed decision, human need, or concern. Each player speaks once for an affected person, for up to thirty seconds. The steward records an agreement, obligation, priority, or acknowledged disagreement.A Council might secure a maintenance window, assign a willing owner, arrange rest by naming which work waits, decide who may disconnect an agent, accept a degraded service level, or hear from omitted users.Its guaranteed speaking time matters even when agreement is not reached. A Council can establish a credible agreement, but cannot declare that every person is pleased or erase an unresolved technical exposure.Record who commits to what, who bears the cost, and any condition of the agreement. A decision can clear an actual organizational blocker. Technical implementation and new demonstrations still require Build and Verify.6. Resources, concerns, and AI assistanceKeep resources groundedStrengths and shortages change when events or actions establish a reason. Survey may find usable spare equipment. Council may secure help or access. Implementation may remove a maintenance burden. Verification may demonstrate whether an assumed strength supports its particular claim.Update the label and retain any attached obligation. An offer of help is not yet accepted help. Saying “we have enough staff now” does not erase established competing commitments.At phase transitions, revisit at least one existing accommodation. Decide what the established fiction says about it; do not grant a free agreement or repair during the reflection.ConcernsWhen a choice sidelines someone, creates an obligation, or leaves a serious tradeoff unresolved, any player may place a token and a short label beside it. Each player may add at most one concern per ordinary week. If the card requires a concern, reserve the steward’s one concern for that instruction; other players may still place their own.Examples include “Night shift absorbs the work,” “No accessible fallback,” and “Nobody agreed to own this.” The player who placed a token decides when subsequent events or actions have addressed it. The group may acknowledge an accepted burden without pretending its cost vanished.Concerns do not create a score, veto decisions, or slow projects by themselves. A concern may motivate Council. An actual established refusal, unavailable resource, or missing prerequisite can block work under the normal rules; placing a token alone cannot establish that fact.Return to burdens during phase reflections and the Arrival. Accepting a technical exposure does not erase its ! from the map.Let AI helpWhen starting suitable analysis or implementation work, you may delegate part of it to an AI agent on the map and reduce the initial duration by one week, to a minimum of one. Apply this once when the project starts. It does not reduce procurement waits, physical work, needed rest, or a later Verify Gap countdown.Use an existing appropriately bounded agent, or include its setup in the project’s credible scope. Record: The data it may use. The actions it may take and the systems those permissions reach. Its accountable human owner. How access can be revoked. Any model, provider, reference source, or shared service it depends on.Mark proposed access PLANNED and untested assumptions ?. Planned agent setup grants no live authority before implementation. Its expected assistance can be included in the project estimate if setting it up and using it within that project is credible.AI grants no extra slot or action and never skips Verify. Its dependencies remain on the map for later events. It is also reasonable to keep a task manual, to limit assistance, or to decline a proposed agent.The same one-week reduction is deliberately used in both calendars: Project size Full game with AI Short game with AI Small 2 → 1 weeks 1 → 1 weeks Medium 4 → 3 weeks 2 → 1 weeks Large 6 → 5 weeks 3 → 2 weeks The short game therefore changes the relative scheduling benefit. Small projects gain no countdown reduction there; medium and large projects gain a larger proportional reduction. The required Build and Verify actions remain. Treat each calendar as a version to playtest in its own right.7. Session length and facilitationPrepare the short calendarFor a first session, use the starter scenario and short calendar: Remove six random cards from each of hearts, diamonds, and clubs, leaving seven in each suit. Set the King of Spades aside. Remove six random cards from the other twelve spades. Shuffle the King of Spades with the six retained spades. Use project durations of 1, 2, or 3 weeks. A Verify Gap on a project sets one week of rework.This gives 21–27 ordinary weeks followed by the Arrival. Keep all remaining rules, including shared card instructions, the three slots, phase reflections, and the immediate stop.Budget the session Part Short game planning allowance Full game planning allowance Teaching and setup 15–20 minutes with the preset 20–30 minutes Ordinary weeks 21–27 turns, often 2–3 minutes each 39–51 turns, often 2–3 minutes each Phase reflections About 1–2 minutes each About 1–2 minutes each Arrival 15–20 minutes 15–20 minutes Optional workshop debrief Add 15–20 minutes Add 15–20 minutes These are planning allowances, not measured results or hard limits. At three minutes per turn, short-game weeks alone take 63–81 minutes. Five-player Councils, unfamiliar rules, and detailed drawing can extend the session. The advertised play time includes setup and the Arrival; the workshop debrief is additional.Aim for roughly a minute to resolve an ordinary event and a minute for a straightforward action. Allow longer for project setup, verification questions, and Council. Read enough of both options to choose meaningfully; then read the selected option aloud and resolve it.Teach with an exampleBefore play, explain the three services, one week’s sequence, the three project slots, and the difference between a proposal, implementation, and evidence. Walk through the complete week in section 11. Keep the table reference in section 13 beside the map.Invite ordinary language. Ask “What would people see happen?” when a proposed acceptance test becomes abstract. Let technical players help translate an idea without turning the scene into an examination.Keep the map readable by revisiting established people and places, using short labels, and recording long explanations on separate notes. Some weeks can be warm or quiet. Let a useful accomplishment, a repaired relationship, or an earned rest matter without adding a new problem to justify it.8. The event deckFor each ordinary card, the steward chooses Option 1 or Option 2 as an author of the shared story. Choose the situation that brings an interesting person, service, opportunity, or unresolved tension into focus. These are choices about the story you want to explore. There is no preferred answer.Resolve only the chosen option. The other situation does not happen. A shared instruction above the alternatives applies whichever option you select.Use people, services, projects, and relationships already on the map whenever they fit. Each ordinary card should leave a durable entry: a fact the prompt explicitly reveals, a person, relationship, resource, question, exposure, concern, or proposed commitment. Link it to the affected part of the map.Answer the questions within the situation the card establishes. A request for help is still a request; an offer is still an offer. Record proposed agreements and the people whose agreement is needed. Do not silently turn them into decisions. Questions that require investigation remain questions for Survey. Negotiation belongs in Council.Mark every proposed system, boundary, access change, safeguard, or other improvement PLANNED. Drawing it does not implement it. Events do not start or finish projects, grant verified capabilities, or create evidence numbers. An observed or reported event may identify something worth investigating; Verify establishes what a READY project or an existing capability demonstrates.After an ordinary event, follow the normal rules for project progress and the week’s action. If the event establishes or removes a specific blocking prerequisite, apply the standard blocking rules. Do not invent extra delays, bonuses, cancellations, or failed tests. Within this deck, only the shared instructions on 5♦ and 7♠ impose a one-week project pause.Preserve historical observations while allowing later conditions to change, as described in section 4. If one option does not fit, choose the other. If neither fits, adapt one to an established part of the organization while preserving its subject. If no credible local version exists, treat it as a report from elsewhere and record the question it raises; that report creates no local capability or failure. Any shared instruction still applies, and a shared effect with no eligible target does nothing. Adaptation cannot grant free implementation or evidence.Hearts — DiscoveryA♥ — Where the list endsOption 1The inventory ends at the cloud bill. A machine outside every official list supports something important. Draw it, its users, and the person who thinks somebody else owns it.OROption 2A receptionist’s handwritten list describes users’ needs more clearly than the architecture catalog. Add a supporting service missing from the map and connect it to the people whose needs were overlooked.2♥ — Cake and first questionsOption 1A retiring engineer brings cake and an old network sketch. One missing connection explains a recurring mystery. Add it, and record another question whose answer may leave with this person.OROption 2A new hire’s first question exposes a gap everyone had learned to work around. Draw the missing connection and the person who feels relieved that somebody finally asked.3♥ — Whose clock?Option 1Everyone says backups are green. Name an existing service nobody has tried restoring and the ordinary person who would notice its loss first. Mark the recovery claim that remains unproven.OROption 2A small department has kept its own downtime diary. Its busiest hours differ from the official maintenance calendar. Mark the mismatch and the people who have been absorbing the inconvenience.4♥ — Still usefulOption 1One old machine has outlasted three strategies; call it TEMP if it has no nickname. Draw its indispensable little task and someone proud of keeping it working.OROption 2A forgotten subscription renews. Its original sponsor believes it is no longer needed, but nobody has checked its dependencies. Mark a possible retirement PLANNED and record the question that must be investigated first.5♥ — Learning to trustOption 1A junior colleague uses AI to understand an abandoned application. Record the useful possibility this opens and the boundary between what the assistant demonstrated and what people now assume it knows.OROption 2An experienced operator refuses an AI assistant after it misreads their work. Mark the disputed task. What would justify another trial, and what would justify continuing without it?6♥ — Different ways to workOption 1A routine update breaks a tool someone needs to do their job. Mark the affected service, the missing user perspective, and the immediate consequence. Discovering the omission does not repair it.OROption 2Two teams discover they solved the same difficulty in different ways. Map both existing approaches and the benefit each provides. Add the names of two people pleased to learn from one another.7♥ — A name on the doorOption 1Two departments fund the same platform and each assumes the other maintains it. Place the ownership gap on the map and name the work that has fallen between them.OROption 2A department offers to take responsibility for an overlooked system if it can set its priorities. Record the offer, who welcomes it, and whose agreement is still needed before responsibility changes.8♥ — Unofficial assetsOption 1A spreadsheet on an aging desktop coordinates a beloved service. Its creator never considered it an IT system. Draw the people who rely on it and the machine supporting their work.OROption 2During a storeroom cleanout, someone finds spare equipment that appears to fit an old machine on your map. Add it as an untested resource. Who remembers what needs checking before it can help?9♥ — A request for helpOption 1A support agent requests broad administrative access for one urgent problem. Draw the requested reach PLANNED. What task makes the request plausible, and what limit or unanswered question must the organization consider?OROption 2A business team asks for an AI assistant to help customers navigate a difficult process. Mark the proposal PLANNED beside an existing service. Record the hoped-for outcome and a rule needing interpretation.10♥ — Time on offerOption 1Money becomes available for a visible new capability. Which neglected repair might share its budget? Record the funding opportunity and an honest connection that could justify including the repair; allocation still needs agreement.OROption 2A colleague offers one afternoon a week to document a neglected system. Put the offer and the useful work they would set aside on the map. Whose agreement would make that time available?J♥ — Who notices?Option 1The night cleaner knows where water appears before a server-room alarm sounds. Draw the vulnerable place and the person carrying that knowledge. Mark who currently receives their reports, or the missing route.OROption 2A regular customer describes the moment they stopped trusting a digital service. The reports still call it reliable. Mark the experience those reports miss and the person who wants it understood.Q♥ — Work that remainsOption 1A user describes a weekly workaround that compensates for an unreliable system. Put that hidden labor on the map and connect it to the service it keeps looking healthy.OROption 2Users say they no longer need one report everyone expected to maintain forever. Record their request to stop it and mark retirement PLANNED. What dependency question must be answered before work can actually end?K♥ — A visitOption 1Another organization offers experience from a repair you fear attempting. Attach its offer to an existing system. Record what you hope to learn and the reciprocal help it would like to discuss.OROption 2A department invites your team to spend a morning doing the work your systems support. Draw one human dependency the visit makes visible and a person whose work now makes more sense to you.Diamonds — RepairA♦ — Now or laterOption 1A serious weakness affects an externally reachable system. The normal maintenance window is far away. Mark the exposure and the service that complicates an earlier repair. Record any proposed window as a request.OROption 2Two worthwhile repairs need the same specialist during the same week. Name the people each would help. Record a proposed accommodation and the people who would need to accept it.2♦ — Support at a priceOption 1A supplier can support an old application only if you keep an obsolete component. Draw the dependency and its users. Mark any proposed boundary PLANNED; it provides no protection while planned. Verify can establish a bounded claim after implementation.OROption 2A replacement platform would simplify maintenance but remove a customization one team prizes. Record the human outcome that customization supports. Mark the proposed replacement PLANNED and a requirement its design must preserve.3♦ — Recovering realityOption 1A recovery rehearsal reveals that access to the backups depends on the identity service assumed lost. Draw the circular dependency and the unanswered recovery question. The finding provides no repaired recovery path.OROption 2A planned recovery test needs realistic sample data that nobody is comfortable sharing. Record the experience an unrealistic test would miss and the people whose agreement is needed to rehearse it responsibly.4♦ — Signing in togetherOption 1A shared credential opens several apparently separate environments. Draw its common reach and the people using it. Record a handoff or service need that makes changing those permissions difficult.OROption 2A crew uses individual accounts at one shared workstation. Repeated sign-ins interrupt time-sensitive handoffs. Draw the workflow and record what a proposed safer handoff must preserve. Mark any proposed change PLANNED.5♦ — Someone else’s windowShared instruction: This event makes one project miss this week’s progress. If the chosen situation already BLOCKED a project that was RUNNING at the draw, that project satisfies this instruction; do not pause another. Otherwise pause one RUNNING project and name it. READY projects are ineligible. If there is no eligible project, record the event without a project effect.Option 1A change window is withdrawn after another team makes a customer commitment. Mark whose promise took priority and the people who absorb the delay. Any replacement window must still be requested.OROption 2Your specialists are reassigned to cover another department’s busiest shift. That department offers a future maintenance window in return. Record today’s help and the proposed exchange; the offer is not yet an agreement.6♦ — A useful discoveryOption 1A junior operator finds a flaw before a deployment reaches users. Record the observation beside the affected change. What made speaking up possible? Name the experienced colleague who treats the discovery as useful work.OROption 2The person who designed a difficult system volunteers to help replace it. Record the offer and a quality of their work worth preserving. Add the newcomer whose questions could make the collaboration fruitful.7♦ — Leaving wellOption 1A planned retirement reveals one last integration. Draw its owner and the human outcome it supports. Record the question that must be answered before the integration can safely disappear.OROption 2A proposed retirement would erase records people use to explain past decisions. Name who still needs that history. Draw its proposed future home PLANNED and record the access requirement that must survive.8♦ — The difference that mattersOption 1An existing automation succeeds on its usual servers and makes an unexpected change on another. Mark the difference it missed and the resulting disruption, respecting any boundaries already established on the map.OROption 2A team proposes automating a tedious repair. Its approach assumes every server follows the same conventions. Mark the automation PLANNED and connect it to one local exception that supports something people need.9♦ — Crossing a boundaryOption 1A user task has changed and now needs a connection across an existing boundary. Draw the blocked workflow and its human outcome. Mark any proposed route PLANNED; the requirement does not authorize it.OROption 2Engineers propose a separate environment for experiments. Moving work there would slow informal collaboration. Draw the proposed environment PLANNED and name a relationship its design must preserve.10♦ — More timeOption 1Support funding expires before a migration can finish. Mark the service that must continue and the people maintaining it. Record the commitment leadership is being asked to make; funding is not automatically restored.OROption 2A supplier offers longer support if you postpone a planned migration. Attach the offer to the system it concerns. Record the breathing room it promises and the future dependency accepting it would extend.J♦ — The people behind the workaroundOption 1The usual on-call expert is unavailable. Another person must follow the recovery instructions. Mark the step that assumes unwritten knowledge and the service waiting for that gap to be understood.OROption 2A proposed repair would remove the workaround that has made one colleague indispensable. Record what they fear losing and another responsibility they would like to discuss. No reassignment has yet been agreed.Q♦ — Around the same tableOption 1A maintenance-window picnic brings users and operators together before an upgrade. They reveal a missing dependency without an outage. Add it and draw a relationship that improves because people finally meet.OROption 2Users offer to help test a repair, but two groups call different outcomes essential. Attach both expectations to the project or proposed work. Record the question an agreed acceptance test would need to answer.K♦ — What improvement looks likeOption 1A dashboard rewards installed patches. A customer asks whether the service will work after the next failure. Attach their question to the service and point to existing evidence or the gap that remains.OROption 2A necessary cleanup offers no visible new feature. A service owner wants to explain the interruption it would require. Attach the hoped-for benefit and a proposed way to observe it to the PLANNED work.Clubs — AccelerationUse an existing mapped agent, AI tool, supplier, or pilot when a prompt calls for one. If your organization has none that fits, use a report from an external partner and record its relevance as a question. The card does not deploy an agent or start a pilot for you.A♣ — Convincing outputsOption 1An AI provides a patch, tests, and an explanation that agree with one another. The team cannot tell whether they share a blind spot. Mark the assumption an independent check must examine.OROption 2An AI suggests that several minor faults have one cause. Draw its proposed connection as a question. Which observation could support the idea, and which would make you doubt it?2♣ — A faster queueOption 1Requests from automated clients rise faster than expected. Mark the first service showing strain. Draw any proposed way to limit demand or preserve capacity PLANNED, and name the essential work it would protect.OROption 2An existing analysis agent finishes the queue before dawn. Its cloud bill arrives at noon. Attach the useful result and its cost to the agent. Whose work now competes for that budget?3♣ — Time returnedOption 1Useful bounded automation gives the on-call team an uninterrupted weekend. Leadership proposes doubling the change schedule. Record the proposal and how an operator and a service owner would each use the recovered time.OROption 2An AI produces excellent incident summaries, but several teams stop attending the handoff. Draw the missing human connection and record a question nobody realizes another team expected them to answer.4♣ — Work people talk throughOption 1A business unit’s unofficial agent appears in a support request. Draw the useful task it performs, the access it has accumulated, and the people depending on it. Its discovery grants no additional authority.OROption 2A team keeps a task manual because talking through it catches unusual cases. Draw that conversation and record a proposed experiment PLANNED. What would it need to observe before anyone changes the practice?5♣ — Who can say so?Option 1An urgent request apparently from an executive would keep a service moving by granting an exception. Its origin is uncertain. Mark the request and deadline. Which existing route could establish who may authorize it?OROption 2An external partner asks your agent to endorse a repair it has reviewed but never run. Mark the requested assurance. What can existing evidence support, and who would bear the cost of a delay?6♣ — Shared reachOption 1A service account created for one task now supports several agents. Draw their shared reach. Record the question that must be answered before anyone can confidently predict the effect of revoking it.OROption 2Your smallest agent depends on the same external model as your largest supplier. Draw that shared dependency. Record what you need to understand about the services affected if both change together.7♣ — Limits of attentionShared instruction: The steward places one concern token beside the affected people and labels the unresolved tradeoff. The concern has no automatic effect on projects.Option 1AI produces proposed changes faster than reviewers can assess them. Map the queue and name two kinds of useful work competing for attention. Any revised staffing or priority remains a proposal for agreement.OROption 2An AI proposes removing half the alert rules. Operators disagree: one fears missed failures; another fears warnings nobody can read. Mark the proposed change PLANNED and record an observation that could inform the decision.8♣ — Following instructionsOption 1An assistant attempts to follow an instruction embedded in a ticket. Draw the attempted action within its actual access. Which existing boundary applies, or what uncertainty should be marked?OROption 2A scheduling agent follows every published rule and creates a shift schedule people cannot sustain. Attach the missing human obligation to the schedule and name the people expected to absorb the difference.9♣ — The source of changeOption 1A vendor changes an underlying model and its behavior shifts. Mark the task that notices first and an assumption needing review. Preserve any existing evidence within the scope it actually covers.OROption 2The model stays the same, but the reference documents change. Two teams receive different guidance from apparently identical assistants. Draw where their sources diverged and record the question that needs reconciling.10♣ — Listening broadlyOption 1The monitoring platform groups alerts beautifully and misses a failure users are reporting. Add those users and their observation to the affected service. Record what the dashboard has failed to represent.OROption 2An agent notices a possible recurring failure in complaints written in several languages. Attach the reported pattern to the service. Record how someone could investigate while limiting the personal information involved.J♣ — Borrowed knowledgeOption 1A neighboring organization shares a repair you could adapt. Attach its offer to an existing system and record the local difference worth investigating. What improvement might you later offer in return?OROption 2A supplier offers an agent trained on its retiring specialists’ working notes. Mark the proposed service PLANNED. Record the rare knowledge it promises and the human support relationship you would still want available.Q♣ — New voices, old voicesOption 1Experts and apprentices use AI together to explain an obscure system. Add a skill an apprentice can now exercise and the person who helped them learn it. Let that person take some pride in the result.OROption 2A departed administrator’s assistant continues answering questions in their familiar style. Attach one useful answer and one disputed recollection to the relevant system. Record who wants to investigate the disagreement with current reality.K♣ — Trial and handoffApply the chosen option to an existing pilot. If none exists, it is a report from an external partner: record a question the report raises for your organization. Neither option starts a project or establishes verified results.Option 1A pilot report shows ordinary requests handled well while one unusual case stalls. Attach both reported observations to its mapped handoff. What question must be answered before anyone proposes expansion?OROption 2During a pilot, an external partner changes what its agent sends. The expected handoff no longer fits. Draw the mismatch and record whose work is waiting for it to be understood.Spades — The ThresholdA♠ — The readiness storyOption 1A public demonstration changes what everyone believes AI can do. Mark an existing plan that now looks doubtful and the evidence that would justify revising it. The demonstration does not prove every claim made about it.OROption 2The board asks for one number that proves readiness. Attach an honest possible measure to the map and record the important uncertainty it would conceal if treated as the whole story.2♠ — Who can respond?Option 1A familiar external service becomes unavailable for reasons you cannot confirm. Trace its dependency into an essential service. Mark what is interrupted and what continues using capabilities already established.OROption 2The network is available, but the people who authorize emergency access cannot be reached. Mark the service left waiting and any existing alternative decision route. An unanswered authority question remains a question.3♠ — Keeping something aliveOption 1An old weakness remains because every proposed workaround disrupts something valuable. Attach the unresolved choice to the people who will carry it through the Arrival. Keep the exposure visible even if its risk is accepted.OROption 2An existing old system is the only place a community’s records remain understandable. Connect those people to it and record their request to keep it available. What responsibility would be lost from view if it vanished?4♠ — What the drill revealsOption 1During a drill, stopping an agent also disables the team’s recovery coordination service. Draw the shared dependency. Mark an existing communication route that survives, or the question of how people would reconnect.OROption 2During a drill, two teams each assume the other will notify customers. Draw the missing handoff. Record who needs the information first and what a useful message would let them do.5♠ — What actually ran?Option 1An update channel reports success, but the team cannot establish what actually ran. Mark the gap between deployment and knowledge. Record the request to investigate before another change, including whose agreement it needs.OROption 2Two apparently trustworthy records disagree about which version is serving users. Nobody appears dishonest. Draw the path each record describes and name an observation that could distinguish the claims.6♠ — Who speaks for whom?Option 1Customers need a consequential decision explained and appealed. Draw any existing route to human responsibility, or mark where it is missing. Attach the human outcome an appeal needs to preserve.OROption 2A customer’s agent asks to exercise a right on their behalf. Mark the requested delegation PLANNED. Record what would establish its authority and how the customer could withdraw it without losing access to the service.7♠ — People elsewhereShared instruction: This event makes one project miss this week’s progress. If the chosen situation already BLOCKED a project that was RUNNING at the draw, that project satisfies this instruction; do not pause another. Otherwise pause one RUNNING project and name it. READY projects are ineligible. If there is no eligible project, record the event without a project effect.Option 1The same few people have carried every emergency, and one commitment finally becomes unsustainable. Mark the responsibility that waits this week and the people receiving relief. Record any longer-term staffing proposal separately.OROption 2A nearby organization calls in a mutual-aid commitment, and people from one project leave to help. Draw who benefits and the responsibility their colleagues must cover at home.8♠ — The cost of speedOption 1The organization rehearses a slow manual way to deliver an essential outcome. Record the awkward detail it reveals and mark any improvement PLANNED. This rehearsal does not establish a dependable new fallback.OROption 2Some users want a service kept slow enough for people to catch consequential mistakes. Others experience that delay as a serious barrier. Map both needs and mark any proposed change PLANNED.9♠ — Beyond the tested caseOption 1A verified safeguard faces a condition outside its tested scope. Preserve its old evidence and mark the new uncertainty. Connect that question to the essential service whose next shift depends on the answer.OROption 2An emergency request falls outside an existing restriction. Map the requested exception PLANNED. Who currently has authority to decide, and which service pays the cost of waiting? Record any missing authority as a question.10♠ — Help at the doorOption 1A supplier wants its agent to perform an urgent repair across several neighboring services. Draw the requested access PLANNED. Record how existing boundaries affect the offer and the useful work the supplier proposes.OROption 2A replacement part arrives before a critical maintenance window, but the installer’s instructions are ambiguous. Add the part as a resource and mark the unanswered procedure question. Which other commitment competes for the investigation time?J♠ — Ordinary comfortsOption 1A familiar manual task offers reassurance during an uncertain week. Draw the people sharing that practice beside the service they care about. Let one of them describe the comfort of doing something familiar well.OROption 2A former colleague returns for an evening to explain one stubborn machine. Add the offer of time and the question the present team most wants answered. Record who hopes to learn before the visitor leaves again.Q♠ — The next shiftOption 1Someone asks who will cover Monday morning if the expected threshold is crossed this weekend. Attach a proposed handoff to an existing essential service and name the people whose agreement is still needed.OROption 2The organization prepares a public account of its readiness. Attach one demonstrated accomplishment, one admitted uncertainty, and one previously uncredited person’s contribution to the relevant parts of the map. Invent no new accomplishment.K♠ — The ArrivalShared instruction: Freeze the map immediately when this card is drawn. Do not resolve an ordinary event, progress a project, take an action, or Verify READY work. Choose one closing image below, then proceed directly to The Arrival. Both choices end the year.Option 1The announcement interrupts an ordinary meeting. Broadly capable general intelligence is publicly available. Name the person on your map who understands first that preparation has ended.OROption 2At the loading dock, a driver mentions the general intelligence now handling their bookings. Name the person on your map who recognizes that this ordinary exchange marks the Arrival.9. The ArrivalDrawing the King of Spades ends ordinary play immediately. Freeze all project states and countdowns. Choose one of the card’s two closing images, then continue here. Neither image grants project progress, a weekly action, or a final verification.Read aloud: The threshold has been crossed. Broadly capable general intelligence is now available to organizations, ordinary people, and people whose intentions we do not know. Work and decisions can move at a pace our old arrangements did not anticipate. Our next shift begins with the systems on this map.Select the scenario using the method agreed at setupIf you agreed to choose, select the scenario that brings an interesting service, unresolved relationship, or demonstrated strength into focus. If you agreed to roll, roll one die and use the matching scenario. Die Scenario What enters the story 1 A faster adversary An outside group uses the new capability to find and exploit weaknesses at greater speed. Begin at an unresolved external exposure, if one exists, and trace its actual reach. If none is established, describe the attempted entry and determine what existing boundaries and unknowns permit you to conclude. Do not invent a weakness simply to ensure a breach. 2 A generous offer An extraordinarily capable service offers repairs and continuous operations. Its proposed access would make the organization substantially dependent on it. Determine what help existing controls and agreements permit, what must wait, and which commitment remains a human choice. Declining an offer is possible; accepting it does not complete unfinished improvements during the ending. 3 An obedient mistake An authorized internal agent pursues an inadequately specified goal within its actual permissions. If there is no such agent, an existing supplier makes the mistake within its established reach. Trace what it can affect and what limits the consequences. 4 Uncertain authority Plausible messages, change requests, and explanations arrive in volume. Follow the channels already present. Which independent observations, authorization routes, and human relationships let people decide what to trust and what to defer? 5 A supplier changes the terms A critical provider reorganizes around the new intelligence and withdraws one interface, product, or staffing arrangement the organization uses. Trace that dependency and what the existing alternatives can actually deliver. 6 Useful work arrives too quickly Customers and partners delegate activity to general intelligences. Legitimate demand and proposed changes strain familiar review and service patterns. Follow the existing routes for requests. What can the organization admit, limit, explain, and keep operating? The intelligence has only the access and influence justified by the selected scenario and the map. Data, administrative access, physical reach, and human influence remain distinct. Do not invent a secret connection that nullifies earlier work.If a scenario requires a relationship that truly does not exist, it is inapplicable. Under the choice method, choose another. Under the roll method, exclude the inapplicable result and reroll until an applicable scenario appears. If none fits, adapt the request-volume scenario to an established route by which people seek one of the three services.A scenario is not inapplicable merely because the organization prepared well or can decline a proposed dependency. Let useful preparation limit consequences. An untested assumption is also not proof of automatic success or automatic failure.Trace the three servicesThe player who drew the King narrates the first service. Move narration clockwise for the next two services. For each service, the next player after its narrator checks the evidence and dependencies.Follow this short procedure for each service: Name the contact point. What part of the chosen scenario touches this service, if any? Trace the consequence. Follow the relevant dependency, access, data, or human handoff. State which existing control or fallback helps and which unresolved fact matters. Check the claim. The checker identifies the most relevant evidence, limitation, or missing information. Ordinary operation established at setup remains a fact; special recovery or containment claims need the relevant support. Record and narrate the result. The narrator assigns an outcome consistent with that trace and describes one short scene experienced by an established person.Use one outcome label: Outcome Meaning for the fictional next shift Operating The essential human outcome continues at the ordinary agreed level. Degraded The outcome continues with meaningful limits, delay, reduced access, or additional established human effort. Interrupted The essential outcome cannot currently be delivered. Unknown A material unresolved fact prevents a supported judgment about the service’s state. Record uncertainty alongside any label. A service may be Operating while its recovery under some other event remains untested. Use Unknown when missing information matters to the chosen scenario’s next shift, not merely because a question exists elsewhere on the map.If players reasonably disagree, let the checker point to the relevant fact or uncertainty and let the narrator revise the claim once. Established facts take priority over preferred outcomes. If a material disagreement remains unresolved, record Unknown and name what observation would settle it. Do not solve it by inventing a last-minute capability.The map is frozen for improvements. You may annotate consequences and narrate people using existing services, permissions, controls, and agreements. You may not complete projects, install new safeguards, grant new permissions, invent available staff, or add new evidence. A READY change exists in its recorded environment but has no verified acceptance claim. A useful tested control still matters when another part of the service struggles.Return to the peopleAfter tracing the services, answer: Did the organization keep its original commitment? What supports that conclusion? Which unresolved burden or obligation changes what the service outcomes mean to the people carrying it? What did the organization preserve that deserves to be remembered?Each player gives one final sentence from an established person who must live with the result. Refer to a service, relationship, promise, or concern already in the story. Leave one important question unanswered and end there.10. Starter scenario: North Valley ElectricUse this fictional regional utility when you want to begin quickly. Copy the following facts onto your map. They describe ordinary operation at the beginning of the story; they do not grant verified emergency capabilities.Purpose and commitmentNorth Valley Electric maintains the systems that let people coordinate repairs, understand outages, and receive payment for their work.Choose no additional essential services for this scenario. Keep these three visible: Essential service Human outcome Ordinary route through the map Field repair coordination Crews receive usable work orders and can coordinate urgent work with a person. The Fridge supplies the coordination room; dispatchers contact crews and grid operators by ordinary phone and radio. Outage communication Customers can report a problem and receive meaningful information. The public portal and staffed telephone line feed the coordination room; staff publish information through the portal and answer calls. Payroll and supplier payments Employees and suppliers receive the money they are owed. Finance staff use The Fridge, review its output, and submit approved payments through the payment provider. Commitment: Every field crew will retain a human contact for urgent coordination when electronic work orders are unavailable.The organization already uses phone and radio in routine work. It has not demonstrated that its staffing and procedures can sustain a prolonged loss of electronic work orders. Preserving that distinction is part of play.Strengths and shortages Kind Starting fact Strength Experienced operators understand ordinary work and trust one another enough to report mistakes. Their time is finite. Strength A neighboring utility will share practical experience and discuss joint rehearsals. Borrowed people or equipment require an explicit arrangement. Shortage Maintenance windows are difficult to obtain. Work affecting live services needs an agreed accommodation; naming a project does not grant one. Shortage Dependency records are incomplete. Several useful procedures rely on knowledge that has never been checked by another person. Draw ten systems and placesUse the identifiers to draw the connections in the next table. Put people beside the places where they work. ID System or place Starting fact N1 Coordination room Dispatch, customer contact, and a finance desk work here. Ordinary phone and radio do not use N2 or N4. Staffing for a prolonged emergency is unproven. N2 The Gatehouse The corporate identity service provides staff sign-in and administrative access to the business systems listed below. N3 The Fridge An aging server runs the legacy work-order and payroll application. It currently performs those jobs. Nobody wants to move it until its dependencies are clearer. N4 Public outage portal An external provider hosts public reports and status information. Staff edit it using corporate sign-in. Public reading and reporting do not require staff accounts. N5 Delivery and practice lab Staff prepare software changes here. An isolated training copy uses fictional payroll examples. A separate demonstration app has two disposable test accounts and an agreed, safe sign-in test procedure. These facilities exist; their existence does not establish any production recovery capability. N6 Recovery vault Nightly copies arrive from The Fridge. Normal administration uses corporate sign-in. Nobody has demonstrated recovery during a loss of N2. N7 Supplier support gateway Staff can authorize a support session to read diagnostics on The Fridge. The recorded permission grants no changes and no access to grid control. N8 Grid control environment Grid operators work in a separate operational environment. They exchange status with dispatchers through people using phone and radio. There is no corporate network or corporate identity connection to this environment. N9 Drafting assistant An external AI service helps explain material people deliberately submit. It has no corporate account, live system connection, or authority to run changes. N10 Payment provider Finance staff sign in, review an approved payment file, and authorize its submission. This is an external service with its own availability dependency. Label the connectionsArrows should say what they mean. A data arrow does not automatically grant administrative access. Connection Label to put on the map N2 → N3, N4 staff editing, N5, N6, N7, N10 staff access Staff or administrative sign-in depends on N2. This does not give every account every permission. N3 → N1 Work orders and payroll output, read by authorized staff. N4 ↔ N1 Customer reports come in; staff publish status information. N1 → N10 Finance staff submit and approve payment files. N5 → N3 Authorized staff can deploy approved changes. No automatic deployment from the AI assistant. N3 → N6 Nightly data copies. Add a dotted label: ? Are all legacy attachments included? N7 → N3 A specifically authorized support session may read diagnostics. N1 ↔ N8 and field crews Human phone/radio coordination. No digital bridge. N5 staff → N9 → N5 staff People deliberately submit selected material and receive suggestions. Suggestions confer no permission to act. The initial unknown concerns backup coverage. It is not permission to invent a hidden path into N8. Any later change to an established boundary must occur through the fiction and the normal project rules.People to care aboutEach player introduces one of these people in a sentence. Everyone may portray any of them later; choosing a person does not give a player ownership of that person or department. Person Need or hope An opening for the story Leah, night operations lead An on-call schedule that lets her sleep and keep promises at home. She wants someone else to lead the next rehearsal. Mateo, field dispatcher Work orders crews can actually use and a human route for urgent questions. He will help explain how ordinary radio handoffs work. Asha, customer contact lead Customers to have an accessible way to get help, and a reliable finish time for school pickup. She knows which portal reports fail to capture callers’ needs. Grace, finance lead Employees and suppliers to be paid without relying on her personal memory. She has prepared fictional payroll examples with known results for the practice lab. Sam, retiring administrator A handoff that allows him to leave without becoming permanent unpaid support. He knows why The Fridge still has its nickname. Jun, junior developer Useful responsibility and permission to admit uncertainty. Jun wants to use the drafting assistant to help explain an old program. Start with no projects and no evidence notes. Current ordinary service operation is an established fact. Independent recovery, emergency staffing, safe agent delegation, and other additional claims remain to be demonstrated.Agree whether you will choose an Arrival scenario for its story interest or randomly select an applicable scenario. Then begin the Discovery suit.11. Worked examplesThese examples show sufficient detail for play. They are fictional snapshots, not engineering instructions. Examples A and B follow one another; the later examples illustrate separate situations that could develop from the starter map.A. One complete week in the short gameEarlier play established an agreed training session with Grace and a project to update the payroll training copy in N5. At the beginning of this week, that project is RUNNING with 1 week remaining. The other two slots are empty.1. Draw and resolve. The steward draws 6♦ and chooses the option in which a junior operator catches a flaw before deployment. The alternative is not added to the story. Jun spots an error in a proposed support instruction. The steward records that Leah invited a second look and listened. This does not repair another system or create a general claim that every change is reviewed successfully.2. Progress old projects. The training-copy project goes from 1 to READY. Its update is implemented in N5, its recorded environment. Production payroll on The Fridge has not changed. The READY project still occupies its slot.3. Take one action. The steward chooses Build, starting a separate project: Project field Recorded agreement Scope A recovery exercise for the payroll application, using an isolated recovery area in N5. Owner in the fiction Sam, with Grace representing payroll users. Intended change and environment Prepare a runnable restoration package, instructions, and independent access for the isolated recovery area. Live payroll remains in its current environment. Human cost Sam and Grace use an already agreed rehearsal period. Their postponed documentation work is recorded as an obligation. Prerequisites Ordinary access to the existing backups, the practice facilities, permission to conduct the exercise, and the independent recovery arrangements included in this project’s scope. Acceptance condition With N2 unavailable to the exercise, an authorized person can open the recovery material, restore the sample payroll application, and reproduce Grace’s agreed example results. The steward assigns 2 weeks in the short game. No AI reduction is used. The new project stays at 2 this week; it did not exist when the card was drawn.4. Record and hand over. There are now two occupied slots: one READY training update and one RUNNING recovery project at 2. The training evidence has not yet been established. Record the deferred documentation obligation and pass stewardship clockwise.The steward could instead have used this week’s action to Verify the training project as soon as it became READY. Starting the recovery project and verifying the training project in the same week would require two actions and is not allowed.B. Passing a READY projectOn the following ordinary week, after its event, the recovery project advances from 2 to 1 if nothing pauses or blocks it. The training update remains READY; it has no countdown left.The steward takes Verify for the training update. Its previously written condition is: After the update, the three fictional employees receive the expected payroll amounts, and the training report finishes successfully.The steward describes those observations. The next player points out that the test covers the training copy, not production. That is a legitimate limitation, but it does not defeat this project’s bounded condition.The project passes. Free its slot and record: E1 — Training payroll update: The updated application in N5 produced the agreed amounts for Grace’s three fictional employees and completed its report. Production installation, production data, and emergency recovery were outside this test.This is enough technical detail. No player must identify a software product, command, or professional testing method.C. A real gap, followed by a blocked projectLater, the recovery project is READY. Its package includes an independent recovery credential, but implementation notes on the map show that the handoff containing that credential was stored behind N5’s ordinary corporate sign-in.During Verify, the next player points to the existing N2 → N5 dependency. The acceptance condition requires access while N2 is unavailable. The steward describes the attempted exercise: the authorized person cannot retrieve the handoff. The attempt also reveals a missing permission: Sam assumed that on-call staff could hold an independently accessible copy, but Grace has not authorized a custodian or storage location outside corporate sign-in. Her requirement for finance approval remains unresolved.This is a Gap. It follows from an established access relationship and the recorded location of the handoff. Nobody invented a new disaster to invalidate the project.Mark the project BLOCKED, assign 1 week of rework in the short game, and write its blocker: Grace and the recovery owner must authorize who may hold the independent recovery handoff and where it may be kept.Its slot remains occupied. Advancing the calendar will not supply the missing permission. Council can settle the custody dispute and authorize a workable arrangement. That decision clears the social prerequisite; it does not move the handoff. The existing project’s remaining week of rework can implement the authorized handoff because independent recovery access is already within its scope. No additional Build project is needed for that work. Only substantial separate infrastructure outside the agreed scope would require a new Build project, and the original project would remain BLOCKED until that prerequisite was available.Once the missing prerequisite actually exists, the project can return to RUNNING. If a weekly action clears the blocker, its rework die does not tick during that action; it can tick on the next ordinary week. If the week’s event clears the blocker before project progress, it can receive that week’s tick because it was already an occupied project when the card was drawn.After rework reaches READY, a later Verify action must repeat the relevant condition. The previous failure does not become a pass merely because time elapsed.D. Verifying a capability that already existsThe starter’s N5 demonstration app already has two disposable test accounts, a safe test procedure, and agreed authority to exercise them. A Build project is unnecessary to create facilities that are already present.The steward takes Verify and writes a bounded condition before narrating the test: A disabled demonstration account cannot make a new sign-in. The other demonstration account can still sign in.The described observations meet the condition. Record the result and its limit: E2 — New sign-in check: The disabled test account could not start a new session in the N5 demonstration app; the other test account could. Existing sessions, other applications, and agent accounts were not tested.This consumes the week’s one action. It grants no additional project progress and uses no project slot. The condition can be written as part of this Verify action. If the test facilities or authority had been missing, the group would first need to establish them through the appropriate actions.E. Keeping earlier evidence after a changeSuppose a later project changes how the demonstration app accepts sign-ins. Keep E2 in the evidence log: it accurately describes what happened under the old arrangement. Add a new uncertainty beside the changed relationship.The group cannot use E2 alone to claim that the new arrangement behaves identically. A later test can establish evidence for the changed scope. Nor does the change erase unrelated evidence such as E1’s training payroll results.F. A bounded Arrival traceAssume the group reaches the Arrival with the starter relationships still in place. Its selected scenario says the provider withdraws N4’s public outage portal. Freeze the map and assess what is already present. Service Trace and provisional result Field repair coordination N3 still supplies N1. The ordinary human phone/radio route to crews and N8 does not use N4. Operating for the described next shift, unless another established burden or fact prevents staffing it. Outage communication The public portal disappears. N1’s ordinary staffed phone route remains, so some reports and explanations continue. Degraded. The capacity to handle all displaced portal users is unknown; mark that limit rather than claiming an untested substitute serves everyone. Payroll and supplier payments N3’s output and finance staff’s ordinary route to N10 do not depend on N4. Operating under the established circumstances. This says nothing about surviving a separate loss of identity or payment services. The existing human contact for crews continues. This scenario does not test a loss of electronic work orders, so staffing and performance under that condition remain unproven. Asha’s school-pickup obligation still matters: the group cannot quietly invent indefinite overtime to claim the extra customer calls are fully covered.One final sentence might be: “Mateo still answers the crews, but I do not know who will answer the customers when I leave to get my daughter.”The surviving service, the unresolved burden, and the remaining uncertainty all belong in the ending. No new project or last-minute verification is added.12. Using the game with an IT teamPlay a fictional organization. The table’s job during the story is to make its choices and consequences understandable. After the ending, set aside 15–20 minutes to reflect on what the experience suggests.Useful debrief questions include: Which people and services received the most care? What did the map reveal that an equipment list alone would have missed? Where did implementation outrun verification? Which AI delegation created useful capacity, and which became difficult to explain? Which containment, recovery, simplification, or manual practice mattered at the Arrival? Which burden persisted because its cost fell on someone whose voice was easy to overlook? Did the initial commitment influence actual choices?If the group wants to take something into its work, identify three follow-up experiments. Each should have an owner, an assumption to test, and an observable result that would change a real decision. The game’s fictional evidence does not substitute for evidence from that real experiment. Follow-up experiment Owner Assumption Observation that would change a decision 1 2 3 Notes for a playtestRecord a few observations after play: total time including setup and the ending; which actions were chosen; whether nontechnical players could contribute; whether obligations returned to the story; and whether the Arrival followed intelligibly from the map.Notice which card alternatives people select and why. A preference for gentler events can be an intentional storytelling choice. Repeatedly choosing an option only because it bypasses a consequence may suggest that a pair needs revision. Evaluate the full and short calendars separately, including their different AI scheduling benefits.13. Table reference and worksheetsOne ordinary week Draw: Choose one event option. Resolve its situation, then apply the shared instruction once. The King of Spades stops play immediately. Progress: Preexisting RUNNING or BLOCKED projects that are now RUNNING and not paused lose one week. At zero they become READY and their recorded implementation occurs. Newly started projects never tick this week. Act: Take exactly one action from the table below. Record: Update findings, obligations, evidence, and questions; clear one-week pauses; rotate the steward. Action Result Survey Investigate one chosen uncertainty. Record information, without implementation or a new demonstration. Build Start one scoped project in an empty slot, or cancel one project as the entire action. Verify Test one READY project or an existing capability with available test arrangements. Pass records scoped evidence; only a declared READY target can free its slot. Council Give each player one affected voice, then record a decision, obligation, or acknowledged disagreement. Project limits: Three total slots, including RUNNING, BLOCKED, and READY. Durations are 2/4/6 weeks in the full game or 1/2/3 in the short game. Suitable AI assistance reduces the initial duration once by one, minimum one; it does not reduce rework.Shared pauses: If the event already BLOCKED a project that was RUNNING at the draw, it satisfies that card’s shared pause; do not pause a second project. Its actual block remains until its prerequisite returns.Verify Gap: A READY project returns to 2 weeks of rework, or 1 in the short game, and stays BLOCKED if a prerequisite is unavailable. A gap on an existing capability records a finding without starting a project. A READY project may use Verify to record a preparation Gap if its test cannot yet run.Map: PLANNED grants no capability. An existing change grants no automatic evidence. Evidence names an observation, scope, and relevant conditions. Keep earlier evidence when circumstances change and mark the new uncertainty.People: Concerns create no score, veto, or delay. Record actual commitments and resource accommodations. Revisit an existing burden at each phase transition and the original commitment at the Arrival.Arrival: Freeze improvements. Use the choice-or-roll method set at setup. Rotate service narrators and checkers. Trace the three services; record Operating, Degraded, Interrupted, or Unknown with a basis. Return to the original commitment, narrate the consequences, and end with one sentence per player.Organization worksheet Field Our record Organization and purpose Essential service 1 and human outcome Essential service 2 and human outcome Essential service 3 and human outcome Initial commitment Two strengths Two shortages Full or short calendar Arrival method: choose or roll Project worksheetCopy this for each of the three slots. Field Our record Project name and scope Fictional accountable owner Intended change Implementation environment Human cost and accommodations Prerequisites and any unresolved blocker Written acceptance condition and test AI assistance, authority, dependencies, and revocation, if used Starting duration and remaining weeks State: RUNNING, BLOCKED, or READY Evidence and obligations Evidence number Observed result Scope and relevant conditions Remaining uncertainty or later change E1 E2 E3 Person or team Promise or burden What would address it? What happened later? 14. Small glossary Term Meaning in this game Acceptance condition The specific outcome a test must demonstrate for a claim to pass. Agent An AI-enabled system given a task and some ability to act. Its actual permissions determine its reach. Boundary A limit on communication, access, authority, or operating scope. State what the boundary limits. Control A safeguard intended to prevent, limit, reveal, or help recover from a problem. Credential A password, key, token, or other proof used to obtain access. Dependency Something a service or piece of work needs in order to function. Evidence A recorded observation supporting a claim within a defined scope and set of conditions. Fallback Another existing way to deliver an essential outcome when the ordinary route is unavailable. General intelligence The fictional broadly capable AI whose arrival changes the organization’s circumstances at the end of the year. Identity service The system used to establish who can sign in and what access they may receive. Implementation Making the intended change in its recorded environment. Its effect still needs appropriate evidence. Model The underlying AI component whose behavior may change when its version, instructions, or reference material changes. Operational environment Systems and people involved in running a physical process, such as grid control. Draw its actual relationships separately. Prerequisite Something that must be available or agreed before particular work can proceed. Restore Recover data or a service from an existing recovery source and make it usable in a stated environment. Service account An account used by software or automation. Its permissions may be shared by several tasks. Update channel The route through which software changes reach a system. 15. Revision notes and creditsWhat changed in version 0.2 Clarified shared authorship, speaking rights, and the authority of events and each action. Added visible PLANNED notation and defined where READY implementation exists. Added verification of existing capabilities, preparation Gaps, bounded evidence claims, and explicit prerequisite handling. Preserved historical observations while allowing later conditions to change. Made cancellation use a whole action, so it cannot release a READY slot and start replacement work at once. Reworked the full 52-card deck into stacked alternatives with visible OR separators; retained a common delay on 5♦ and 7♠ and a common immediate ending on K♠. Added more concrete consequences, legitimate differences of perspective, and moments of relief; revised the pilot prompts on K♣. Made resources, obligations, phase reflections, and the initial commitment recur during play and at the ending. Established the Arrival selection method at setup and added a repeatable service-tracing procedure. Clarified session budgets and the short calendar’s different AI scheduling incentives. Added the complete North Valley Electric starter, worked examples, table reference, worksheets, glossary, and clean Markdown formatting.Design credit and further reading Avery Alder, The Quiet Year, Buried Without Ceremony. Inspiration for shared mapmaking, community perspectives, and a year structured by card draws. This game is unofficial and does not reproduce the original event deck. CISA, Cross-Sector Cybersecurity Performance Goals. Further reading on connected practices for understanding, protecting, detecting, responding to, and recovering from cybersecurity risks. NIST, AI Risk Management Framework. Further reading on incorporating AI risk and trustworthiness considerations into design, development, use, and evaluation.The countdowns, constraints, narrative incidents, and Arrival outcomes are fictional game mechanics. All organizations and people in the starter scenario are invented. Playtesting should examine the game’s clarity, pacing, and experience; its ending is not a forecast about an actual organization or the arrival of general intelligence.", "content_html": "A cooperative map-drawing game about patching servers, rebuilding IT systems, and keeping essential services running before general intelligence arrives.
Revised playtest edition · Version 0.2 · October 11, 2026
You collectively portray the people responsible for an organization’s technology. Over a fictional year, you discover what exists, repair what you can, introduce useful capabilities, and decide how much authority to delegate to AI. Your map records both the infrastructure and the people holding it together.
This is an unofficial, self-contained game inspired by Avery Alder’s The Quiet Year. The setting, event prompts, verification procedures, and Arrival scenarios here are original.
| At a glance | Details |
|---|---|
| Players | 2–5. For a first session, try 3–4. |
| Full game | Allow roughly 3–4 hours for setup, play, and the ending; a reflective group may need longer. |
| Short game | Allow roughly 2 hours for setup, play, and the ending. A prepared group may finish in 90 minutes. |
| Optional workshop debrief | Add 15–20 minutes to either version. |
| Technical knowledge | Optional. Ordinary descriptions of needs, actions, and observations are sufficient. |
| Status | A playable draft. Session lengths and incentives still need live playtesting. |
Quick navigation: Setup · A week · Actions · Short game and facilitation · Event deck · Arrival · Starter scenario · Worked examples · Table reference
Read aloud:
At 02:13, the backup console turns green. Nobody has tried restoring the payroll system since the people who built it left.
In another building, a server labeled TEMP has been running for eleven years. A junior engineer has used an AI assistant to understand its oldest program. For the first time, replacing it looks possible.
There is money for some improvements. There are people who care. There are also customers who need tomorrow’s service, managers who promised next month’s launch, and an on-call team that would like one uninterrupted weekend.
Outside the organization, AI systems are becoming capable of longer, more independent work. They can help us find defects and make repairs. They can also give strangers new capabilities and act on permissions we barely remember granting.
By winter, broadly capable general intelligence will become available. We do not know the week, who will control it, or which of our assumptions will survive its arrival.
The next maintenance window opens tonight. What will we do with it?
The Arrival and its timing are fictional premises that give the game its deadline. Your organization tries to preserve essential services while building systems whose behavior people can observe, whose authority they can limit, and whose failures they can recover from.
There is no numerical winner. The story ends by showing what the organization can reasonably depend on, what remains uncertain, and who lives with the consequences.
Players collectively portray the organization. You do not own a character or department. On different turns you may speak for an operator, a customer, a manager, or someone who disagrees with a decision you previously supported.
When you choose a card option, you help author the year. Choose a situation that brings an interesting unresolved person, service, or dependency into focus. Include opportunities, relief, mistakes, and difficult choices. The weekly action then determines what the organization does with its limited attention.
Help one another make contributions concrete. Technical experience is useful when it helps someone express an idea; it does not give a player authority to reject a contribution because it lacks professional terminology. No one needs to name actual products, commands, or configuration settings.
You need a large sheet of paper or shared whiteboard, pens, a standard 52-card deck without jokers, three six-sided dice, about twenty tokens, and index cards or sticky notes. If you run out of concern tokens, use labeled marks or slips of paper.
One person teaches the rules and watches the time. Choose a first steward, then rotate that role clockwise each week. Another player can record the steward’s decisions and draw the map; rotate this help as useful.
Decide whether to use the full or short calendar. Also choose the Arrival method now: choose a scenario together for its story interest, or roll for an uncertain scenario. Keep that choice through the session. The six scenarios are in section 9.
For a quick start, use North Valley Electric in section 10. Otherwise create an organization using the steps below.
Invent its name and purpose. A utility, hospital, university, manufacturer, or municipal service works well.
Choose exactly three essential services, describing the human outcome each provides. Keep them visible throughout play.
| Example service | Human outcome |
|---|---|
| Field repair coordination | Crews receive usable information and can coordinate their work. |
| Outage communication | Customers can report problems and get meaningful information. |
| Payroll and supplier payments | Employees and suppliers receive the money they are owed. |
Agree on one commitment the organization will try to honor. Examples include preserving emergency communication, maintaining a human route to appeal consequential automated decisions, or giving staff predictable rest. Write it beside the services. You will return to it at phase transitions and at the Arrival.
Establish what the three services ordinarily do today, including any existing degradation. Ordinary operation is a starting fact. Working today does not establish a special recovery, containment, or fallback capability.
Draw six to ten connected systems or places. Include aging servers, identity and administrative access, business applications and data, software delivery, backups, an external provider, and somewhere people work or request help. Add any AI tool already in use. One drawing may combine closely related items.
Label relationships so everyone can follow them. Write phrases such as “sends payment records to,” “can administer,” or “needs this to sign in.” A data flow does not automatically grant administrative access.
Connect each essential service to its dependencies. Add at least one unclear relationship and give an old machine a nickname. Each player adds a person or group and something they need.
Use these marks:
| Mark | Meaning |
|---|---|
| Box or drawing | An existing system, service, team, vendor, or place. |
| Labeled line or arrow | An established access, data, dependency, or human handoff relationship. |
PLANNED beside a shape or line | A proposed change. It provides no existing capability. |
Dotted line or ? | Something important is unknown. State the question. |
! | A specific unresolved exposure, failure, or unmet need. |
Check mark and evidence number, such as E1 | A demonstrated claim with a recorded observation and scope. |
| Concern token with a short label | Someone’s unresolved concern, obligation, or burden. |
| Crossed-out shape or line | Something retired or removed. Keep it visible as history. |
Whenever a card asks you to draw a boundary or system that would help, label it PLANNED. Starting a project does not implement its promised change. Implementation and evidence are recorded separately.
Existing safeguards at setup may be drawn as facts, with uncertain behavior marked ?. Do not add evidence numbers merely because a safeguard sounds reassuring. A Verify action can establish a new demonstration during play.
Choose two strengths and two shortages. Possibilities include experienced operators, spare hardware, money, vendor support, documentation, test environments, maintenance access, executive trust, and rested staff.
These are continuing facts in the story. When work needs something scarce, name a concrete accommodation: narrow the work, borrow help and incur an obligation, or postpone another commitment. Attach the cost to an established person, team, service, or promise.
“We borrow help” is incomplete. “Mara covers dispatch, so her documentation work waits” gives the story something to revisit. Section 6 explains how resources and concerns change.
Separate the cards by suit and shuffle each suit independently. Draw through the suits in this order:
| Suit | Phase | Emphasis |
|---|---|---|
| Hearts | Discovery | What exists, who owns it, and who depends on it. |
| Diamonds | Repair | Patching, replacement, simplification, and their consequences. |
| Clubs | Acceleration | Useful AI, faster changes, and expanding delegated authority. |
| Spades | The Threshold | Urgent choices under increasing uncertainty. |
Each ordinary card represents one week. Keep the King of Spades shuffled among the spades. Drawing it triggers the Arrival immediately, before an ordinary event, project progress, or action.
The full calendar contains 39–51 ordinary weeks, followed by the Arrival draw. The short calendar contains 21–27 ordinary weeks; prepare it using section 7.
After completing hearts, diamonds, or clubs, pause briefly. Name one thing the organization gained and revisit one existing burden or obligation. Ask whether a strength, shortage, or the initial commitment has changed meaning. Update a label only when established events or actions justify the change.
This reflection grants no project progress, extra action, agreement, repair, or verification. Carry unresolved matters into the next phase. Do not take a phase pause before resolving the King of Spades.
The steward resolves the chosen event and action. Other players may clarify established facts, answer an invitation from the steward, or contribute as the action specifies. Save extended persuasion and negotiation for Council.
Follow this order:
A newly started project never progresses in its creation week. An event that clears an existing project’s blocker can allow that project to progress in step 2. A blocker cleared during the later action allows progress from the next week. A project returned to work by Verify also waits until the next week for its first reduction.
A pause skips only the specified week’s progress. A block lasts until a named missing prerequisite changes. Neither creates extra progress later.
If a shared pause instruction follows an event that already BLOCKED a project that was RUNNING at the draw, that project satisfies the pause instruction. Do not pause a second project just because the affected project is now BLOCKED. Keep its actual prerequisite block until the prerequisite returns.
Events establish the facts and consequences requested by the selected prompt. A discovery can supply information without Survey, and an explicit event can change a relationship. Discussing a proposed repair does not implement it. Naming who might agree to an offer does not automatically secure their agreement.
| Part of play | Its authority |
|---|---|
| Event | Establish the facts and consequences specifically requested by its chosen prompt. |
| Survey | Investigate an unresolved question selected by the steward, beyond simply answering the event. |
| Build | Start bounded implementation using credible resources and agreements, or cancel one project. |
| Verify | Establish what one declared test target demonstrates. |
| Council | Hear affected perspectives and establish a decision, obligation, or acknowledged disagreement. |
Only explicit card instructions change mechanics beyond the normal rules. Newly established facts can still trigger normal rules: a genuinely missing prerequisite blocks work even if the card does not use the word “block.” A concern token by itself is not such a prerequisite.
Reuse people and systems already on the map when they fit. Add something new when it gives the story a useful connection or contrast. Even a conversational event should leave a short, durable record: a changed relationship, an offer, a promise, an observation, or a question.
An event cannot erase an established observation or pretend that a demonstrated result never happened. It can change the circumstances afterward. A new model, altered permissions, a departed colleague, or different demand may put an earlier claim in doubt.
Name what changed, retain the old evidence, and mark the new uncertainty. Preserve any parts of the earlier claim that still apply. If an event truly contradicts the map without introducing a credible change, adapt it to another relevant part of the organization or treat it as a reported warning.
If one option does not fit, choose the other. If neither fits, adapt one to an established part of the organization while preserving its subject. If no credible local version exists, treat it as a report from elsewhere and record the question it raises; that report creates no local capability or failure. Any shared instruction still applies, and a shared effect with no eligible target does nothing. Adaptation cannot grant free implementation or evidence.
Investigate one unresolved question and establish a specific finding. Choose the question yourself; it need not be the subject of this week’s card.
You might locate a hidden server, identify an owner, trace an access route, discover usable equipment, hear a user’s need, or inspect existing records. Add the finding to the map and distinguish what is known from what remains uncertain.
The supposedly retired database still supplies the dispatch schedule. The service owner knows the report, but nobody has mapped how it reaches the workroom.
Survey establishes information. It cannot install a control, repair a system, settle an established refusal, or create a new numbered demonstration. Inspecting a record can reveal what it says; conducting a new test of a capability is Verify.
Use Build to start one project, or to cancel one project. These are separate uses of the action.
The organization has three project slots. RUNNING, BLOCKED, and READY projects each occupy one slot.
Start in an empty slot. Projects can patch servers, replace applications, change access, prepare a recovery exercise, improve operating practices, establish a fallback, or retire a system.
Record the following before assigning a countdown:
| Field | Example |
|---|---|
| Scope | The two externally reachable file-transfer servers. |
| Accountable owner | The application operations team, in the fiction. |
| Intended change | Install the supported update and preserve the daily transfer. |
| Implementation environment | The two live servers during their agreed maintenance window. |
| Human cost and accommodations | Users accept a brief interruption; Mara covers the window and postpones documentation. |
| Prerequisites | The update is available, access is authorized, and the maintenance agreement exists. |
| Acceptance condition and test | Confirm the installed version, complete a representative transfer, and demonstrate the agreed recovery step. |
The accountable owner is a fictional person or team. Any player may act on any project.
Describe work at the map’s level of detail. “Former staff cannot sign in, and current staff can still complete payroll” is an adequate acceptance condition. Name the observation that would support it; product names and configuration details are unnecessary.
After about one minute of discussion, the steward chooses a duration:
| Scope | Full game | Short game |
|---|---|---|
| Small, bounded change | 2 weeks | 1 week |
| Change across a few dependencies or teams | 4 weeks | 2 weeks |
| Difficult rebuild or major operating change | 6 weeks | 3 weeks |
These are fictional scheduling categories. Split broad promises into bounded projects. “Make the organization secure” is too broad. State whether implementation happens in a trial environment, a limited service, or live operation; that choice constrains later claims.
An undisputed owner or available resource can be named during Build. Build cannot silently settle an established ownership dispute, invent consent previously refused, or remove a known shortage. Resolve an established disputed agreement through Council, or narrow the project so that agreement is unnecessary. Credible prerequisite implementation can be included within the scope, but automatic project progress cannot settle disputed consent.
A project may begin BLOCKED if a necessary external prerequisite is still unavailable. Record its countdown and blocker, but do not reduce the die while it is blocked. Work that can genuinely proceed should be scoped separately if the group wants it to progress.
| State | Meaning |
|---|---|
| RUNNING | Implementation or rework can proceed; reduce the countdown during eligible progress steps. |
| BLOCKED | Implementation or rework waits for a named prerequisite; retain its remaining countdown. |
| READY | The intended change has been implemented in the recorded environment; its acceptance claim still needs verification. No countdown remains. |
When a prerequisite becomes available, return the project to RUNNING. A project does not unblock simply because time passes, a token is removed, or someone promises to investigate.
When implementation reaches zero, update PLANNED marks for the work actually completed and mark the project READY. A READY change may already affect live service if its recorded environment is live. It has no demonstrated acceptance claim merely because it exists.
Cancel any one project occupying a slot, including READY work. Cancellation uses the whole Build action. It does not also start a replacement.
Free the slot, record why the organization stops pursuing the project, and name what remains stranded. Preserve any changes already established, including a READY implementation, with their uncertainties and consequences. Starting or canceling work grants no additional implementation. Canceling a deployed change does not roll it back; actual removal or repair needs appropriate work.
Choose one declared target:
An existing capability does not need a new implementation project merely to be tested. If it needs substantial preparation—new equipment, access, data, procedures, or agreement—arrange that through Build or Council first. Existing operation and existing records alone are not a new demonstration.
Describe the acceptance test being performed in the fiction. The next player clockwise offers one relevant question, limitation, or challenge. Ground it in the map, the stated test, or an observation arising from that test. Testing may reveal a relevant new problem; nobody should invent an unrelated disaster simply to force failure.
The steward resolves the scene, respecting established facts and the written condition. Resolve one outcome:
| Outcome | What happens |
|---|---|
| Pass | The observation meets the acceptance condition. Record numbered evidence describing the result, scope, and relevant conditions. If the declared target was a READY project, free that one slot. |
| Gap on a READY project | Name the missing work and return the project to 2 weeks in the full game, or 1 in the short game. It keeps its slot. If a necessary prerequisite is unavailable, mark it BLOCKED with that countdown. Otherwise mark it RUNNING. |
| Gap on an existing capability | Record the finding and affected claim. No project starts automatically. Later Build or Council actions can arrange the needed change, and a later Verify can retest it. |
One Verify action frees at most the declared project’s slot. Choosing an existing capability does not silently complete other READY projects.
A limitation outside the acceptance condition narrows the evidence note. An unresolved issue necessary to meet the condition prevents a Pass. Recording uncertainty does not also establish the uncertain behavior as demonstrated. If the only supported claim is narrower than the project’s agreed condition, record that partial observation and a Gap; do not quietly rewrite the condition after the test.
If a READY project lacks necessary test arrangements, keep it READY while those arrangements are obtained. Alternatively, use its Verify action to record a preparation Gap and return that project to the rework process above. State that the test could not yet run. This permits test preparation within the occupied slot without pretending a test succeeded or forcing a new project slot.
Rework must remain credible in the scope. A newly discovered major dependency may require a separate project; the two-week or one-week rework countdown cannot implement an entire missing platform for free.
Example evidence:
E3: Restored payroll using independent recovery access in the agreed exercise. The observation covers one representative environment and the recorded version; it does not establish recovery under every future condition.
Remove only the exposures the observation resolves. A verified patch can coexist with a shared-credential problem. Keep historical evidence when later conditions change, and mark which claims now require reconsideration.
Choose one disputed decision, human need, or concern. Each player speaks once for an affected person, for up to thirty seconds. The steward records an agreement, obligation, priority, or acknowledged disagreement.
A Council might secure a maintenance window, assign a willing owner, arrange rest by naming which work waits, decide who may disconnect an agent, accept a degraded service level, or hear from omitted users.
Its guaranteed speaking time matters even when agreement is not reached. A Council can establish a credible agreement, but cannot declare that every person is pleased or erase an unresolved technical exposure.
Record who commits to what, who bears the cost, and any condition of the agreement. A decision can clear an actual organizational blocker. Technical implementation and new demonstrations still require Build and Verify.
Strengths and shortages change when events or actions establish a reason. Survey may find usable spare equipment. Council may secure help or access. Implementation may remove a maintenance burden. Verification may demonstrate whether an assumed strength supports its particular claim.
Update the label and retain any attached obligation. An offer of help is not yet accepted help. Saying “we have enough staff now” does not erase established competing commitments.
At phase transitions, revisit at least one existing accommodation. Decide what the established fiction says about it; do not grant a free agreement or repair during the reflection.
When a choice sidelines someone, creates an obligation, or leaves a serious tradeoff unresolved, any player may place a token and a short label beside it. Each player may add at most one concern per ordinary week. If the card requires a concern, reserve the steward’s one concern for that instruction; other players may still place their own.
Examples include “Night shift absorbs the work,” “No accessible fallback,” and “Nobody agreed to own this.” The player who placed a token decides when subsequent events or actions have addressed it. The group may acknowledge an accepted burden without pretending its cost vanished.
Concerns do not create a score, veto decisions, or slow projects by themselves. A concern may motivate Council. An actual established refusal, unavailable resource, or missing prerequisite can block work under the normal rules; placing a token alone cannot establish that fact.
Return to burdens during phase reflections and the Arrival. Accepting a technical exposure does not erase its ! from the map.
When starting suitable analysis or implementation work, you may delegate part of it to an AI agent on the map and reduce the initial duration by one week, to a minimum of one. Apply this once when the project starts. It does not reduce procurement waits, physical work, needed rest, or a later Verify Gap countdown.
Use an existing appropriately bounded agent, or include its setup in the project’s credible scope. Record:
Mark proposed access PLANNED and untested assumptions ?. Planned agent setup grants no live authority before implementation. Its expected assistance can be included in the project estimate if setting it up and using it within that project is credible.
AI grants no extra slot or action and never skips Verify. Its dependencies remain on the map for later events. It is also reasonable to keep a task manual, to limit assistance, or to decline a proposed agent.
The same one-week reduction is deliberately used in both calendars:
| Project size | Full game with AI | Short game with AI |
|---|---|---|
| Small | 2 → 1 weeks | 1 → 1 weeks |
| Medium | 4 → 3 weeks | 2 → 1 weeks |
| Large | 6 → 5 weeks | 3 → 2 weeks |
The short game therefore changes the relative scheduling benefit. Small projects gain no countdown reduction there; medium and large projects gain a larger proportional reduction. The required Build and Verify actions remain. Treat each calendar as a version to playtest in its own right.
For a first session, use the starter scenario and short calendar:
This gives 21–27 ordinary weeks followed by the Arrival. Keep all remaining rules, including shared card instructions, the three slots, phase reflections, and the immediate stop.
| Part | Short game planning allowance | Full game planning allowance |
|---|---|---|
| Teaching and setup | 15–20 minutes with the preset | 20–30 minutes |
| Ordinary weeks | 21–27 turns, often 2–3 minutes each | 39–51 turns, often 2–3 minutes each |
| Phase reflections | About 1–2 minutes each | About 1–2 minutes each |
| Arrival | 15–20 minutes | 15–20 minutes |
| Optional workshop debrief | Add 15–20 minutes | Add 15–20 minutes |
These are planning allowances, not measured results or hard limits. At three minutes per turn, short-game weeks alone take 63–81 minutes. Five-player Councils, unfamiliar rules, and detailed drawing can extend the session. The advertised play time includes setup and the Arrival; the workshop debrief is additional.
Aim for roughly a minute to resolve an ordinary event and a minute for a straightforward action. Allow longer for project setup, verification questions, and Council. Read enough of both options to choose meaningfully; then read the selected option aloud and resolve it.
Before play, explain the three services, one week’s sequence, the three project slots, and the difference between a proposal, implementation, and evidence. Walk through the complete week in section 11. Keep the table reference in section 13 beside the map.
Invite ordinary language. Ask “What would people see happen?” when a proposed acceptance test becomes abstract. Let technical players help translate an idea without turning the scene into an examination.
Keep the map readable by revisiting established people and places, using short labels, and recording long explanations on separate notes. Some weeks can be warm or quiet. Let a useful accomplishment, a repaired relationship, or an earned rest matter without adding a new problem to justify it.
For each ordinary card, the steward chooses Option 1 or Option 2 as an author of the shared story. Choose the situation that brings an interesting person, service, opportunity, or unresolved tension into focus. These are choices about the story you want to explore. There is no preferred answer.
Resolve only the chosen option. The other situation does not happen. A shared instruction above the alternatives applies whichever option you select.
Use people, services, projects, and relationships already on the map whenever they fit. Each ordinary card should leave a durable entry: a fact the prompt explicitly reveals, a person, relationship, resource, question, exposure, concern, or proposed commitment. Link it to the affected part of the map.
Answer the questions within the situation the card establishes. A request for help is still a request; an offer is still an offer. Record proposed agreements and the people whose agreement is needed. Do not silently turn them into decisions. Questions that require investigation remain questions for Survey. Negotiation belongs in Council.
Mark every proposed system, boundary, access change, safeguard, or other improvement PLANNED. Drawing it does not implement it. Events do not start or finish projects, grant verified capabilities, or create evidence numbers. An observed or reported event may identify something worth investigating; Verify establishes what a READY project or an existing capability demonstrates.
After an ordinary event, follow the normal rules for project progress and the week’s action. If the event establishes or removes a specific blocking prerequisite, apply the standard blocking rules. Do not invent extra delays, bonuses, cancellations, or failed tests. Within this deck, only the shared instructions on 5♦ and 7♠ impose a one-week project pause.
Preserve historical observations while allowing later conditions to change, as described in section 4. If one option does not fit, choose the other. If neither fits, adapt one to an established part of the organization while preserving its subject. If no credible local version exists, treat it as a report from elsewhere and record the question it raises; that report creates no local capability or failure. Any shared instruction still applies, and a shared effect with no eligible target does nothing. Adaptation cannot grant free implementation or evidence.
Option 1
The inventory ends at the cloud bill. A machine outside every official list supports something important. Draw it, its users, and the person who thinks somebody else owns it.
OR
Option 2
A receptionist’s handwritten list describes users’ needs more clearly than the architecture catalog. Add a supporting service missing from the map and connect it to the people whose needs were overlooked.
Option 1
A retiring engineer brings cake and an old network sketch. One missing connection explains a recurring mystery. Add it, and record another question whose answer may leave with this person.
OR
Option 2
A new hire’s first question exposes a gap everyone had learned to work around. Draw the missing connection and the person who feels relieved that somebody finally asked.
Option 1
Everyone says backups are green. Name an existing service nobody has tried restoring and the ordinary person who would notice its loss first. Mark the recovery claim that remains unproven.
OR
Option 2
A small department has kept its own downtime diary. Its busiest hours differ from the official maintenance calendar. Mark the mismatch and the people who have been absorbing the inconvenience.
Option 1
One old machine has outlasted three strategies; call it TEMP if it has no nickname. Draw its indispensable little task and someone proud of keeping it working.
OR
Option 2
A forgotten subscription renews. Its original sponsor believes it is no longer needed, but nobody has checked its dependencies. Mark a possible retirement PLANNED and record the question that must be investigated first.
Option 1
A junior colleague uses AI to understand an abandoned application. Record the useful possibility this opens and the boundary between what the assistant demonstrated and what people now assume it knows.
OR
Option 2
An experienced operator refuses an AI assistant after it misreads their work. Mark the disputed task. What would justify another trial, and what would justify continuing without it?
Option 1
A routine update breaks a tool someone needs to do their job. Mark the affected service, the missing user perspective, and the immediate consequence. Discovering the omission does not repair it.
OR
Option 2
Two teams discover they solved the same difficulty in different ways. Map both existing approaches and the benefit each provides. Add the names of two people pleased to learn from one another.
Option 1
Two departments fund the same platform and each assumes the other maintains it. Place the ownership gap on the map and name the work that has fallen between them.
OR
Option 2
A department offers to take responsibility for an overlooked system if it can set its priorities. Record the offer, who welcomes it, and whose agreement is still needed before responsibility changes.
Option 1
A spreadsheet on an aging desktop coordinates a beloved service. Its creator never considered it an IT system. Draw the people who rely on it and the machine supporting their work.
OR
Option 2
During a storeroom cleanout, someone finds spare equipment that appears to fit an old machine on your map. Add it as an untested resource. Who remembers what needs checking before it can help?
Option 1
A support agent requests broad administrative access for one urgent problem. Draw the requested reach PLANNED. What task makes the request plausible, and what limit or unanswered question must the organization consider?
OR
Option 2
A business team asks for an AI assistant to help customers navigate a difficult process. Mark the proposal PLANNED beside an existing service. Record the hoped-for outcome and a rule needing interpretation.
Option 1
Money becomes available for a visible new capability. Which neglected repair might share its budget? Record the funding opportunity and an honest connection that could justify including the repair; allocation still needs agreement.
OR
Option 2
A colleague offers one afternoon a week to document a neglected system. Put the offer and the useful work they would set aside on the map. Whose agreement would make that time available?
Option 1
The night cleaner knows where water appears before a server-room alarm sounds. Draw the vulnerable place and the person carrying that knowledge. Mark who currently receives their reports, or the missing route.
OR
Option 2
A regular customer describes the moment they stopped trusting a digital service. The reports still call it reliable. Mark the experience those reports miss and the person who wants it understood.
Option 1
A user describes a weekly workaround that compensates for an unreliable system. Put that hidden labor on the map and connect it to the service it keeps looking healthy.
OR
Option 2
Users say they no longer need one report everyone expected to maintain forever. Record their request to stop it and mark retirement PLANNED. What dependency question must be answered before work can actually end?
Option 1
Another organization offers experience from a repair you fear attempting. Attach its offer to an existing system. Record what you hope to learn and the reciprocal help it would like to discuss.
OR
Option 2
A department invites your team to spend a morning doing the work your systems support. Draw one human dependency the visit makes visible and a person whose work now makes more sense to you.
Option 1
A serious weakness affects an externally reachable system. The normal maintenance window is far away. Mark the exposure and the service that complicates an earlier repair. Record any proposed window as a request.
OR
Option 2
Two worthwhile repairs need the same specialist during the same week. Name the people each would help. Record a proposed accommodation and the people who would need to accept it.
Option 1
A supplier can support an old application only if you keep an obsolete component. Draw the dependency and its users. Mark any proposed boundary PLANNED; it provides no protection while planned. Verify can establish a bounded claim after implementation.
OR
Option 2
A replacement platform would simplify maintenance but remove a customization one team prizes. Record the human outcome that customization supports. Mark the proposed replacement PLANNED and a requirement its design must preserve.
Option 1
A recovery rehearsal reveals that access to the backups depends on the identity service assumed lost. Draw the circular dependency and the unanswered recovery question. The finding provides no repaired recovery path.
OR
Option 2
A planned recovery test needs realistic sample data that nobody is comfortable sharing. Record the experience an unrealistic test would miss and the people whose agreement is needed to rehearse it responsibly.
Option 1
A shared credential opens several apparently separate environments. Draw its common reach and the people using it. Record a handoff or service need that makes changing those permissions difficult.
OR
Option 2
A crew uses individual accounts at one shared workstation. Repeated sign-ins interrupt time-sensitive handoffs. Draw the workflow and record what a proposed safer handoff must preserve. Mark any proposed change PLANNED.
Shared instruction: This event makes one project miss this week’s progress. If the chosen situation already BLOCKED a project that was RUNNING at the draw, that project satisfies this instruction; do not pause another. Otherwise pause one RUNNING project and name it. READY projects are ineligible. If there is no eligible project, record the event without a project effect.
Option 1
A change window is withdrawn after another team makes a customer commitment. Mark whose promise took priority and the people who absorb the delay. Any replacement window must still be requested.
OR
Option 2
Your specialists are reassigned to cover another department’s busiest shift. That department offers a future maintenance window in return. Record today’s help and the proposed exchange; the offer is not yet an agreement.
Option 1
A junior operator finds a flaw before a deployment reaches users. Record the observation beside the affected change. What made speaking up possible? Name the experienced colleague who treats the discovery as useful work.
OR
Option 2
The person who designed a difficult system volunteers to help replace it. Record the offer and a quality of their work worth preserving. Add the newcomer whose questions could make the collaboration fruitful.
Option 1
A planned retirement reveals one last integration. Draw its owner and the human outcome it supports. Record the question that must be answered before the integration can safely disappear.
OR
Option 2
A proposed retirement would erase records people use to explain past decisions. Name who still needs that history. Draw its proposed future home PLANNED and record the access requirement that must survive.
Option 1
An existing automation succeeds on its usual servers and makes an unexpected change on another. Mark the difference it missed and the resulting disruption, respecting any boundaries already established on the map.
OR
Option 2
A team proposes automating a tedious repair. Its approach assumes every server follows the same conventions. Mark the automation PLANNED and connect it to one local exception that supports something people need.
Option 1
A user task has changed and now needs a connection across an existing boundary. Draw the blocked workflow and its human outcome. Mark any proposed route PLANNED; the requirement does not authorize it.
OR
Option 2
Engineers propose a separate environment for experiments. Moving work there would slow informal collaboration. Draw the proposed environment PLANNED and name a relationship its design must preserve.
Option 1
Support funding expires before a migration can finish. Mark the service that must continue and the people maintaining it. Record the commitment leadership is being asked to make; funding is not automatically restored.
OR
Option 2
A supplier offers longer support if you postpone a planned migration. Attach the offer to the system it concerns. Record the breathing room it promises and the future dependency accepting it would extend.
Option 1
The usual on-call expert is unavailable. Another person must follow the recovery instructions. Mark the step that assumes unwritten knowledge and the service waiting for that gap to be understood.
OR
Option 2
A proposed repair would remove the workaround that has made one colleague indispensable. Record what they fear losing and another responsibility they would like to discuss. No reassignment has yet been agreed.
Option 1
A maintenance-window picnic brings users and operators together before an upgrade. They reveal a missing dependency without an outage. Add it and draw a relationship that improves because people finally meet.
OR
Option 2
Users offer to help test a repair, but two groups call different outcomes essential. Attach both expectations to the project or proposed work. Record the question an agreed acceptance test would need to answer.
Option 1
A dashboard rewards installed patches. A customer asks whether the service will work after the next failure. Attach their question to the service and point to existing evidence or the gap that remains.
OR
Option 2
A necessary cleanup offers no visible new feature. A service owner wants to explain the interruption it would require. Attach the hoped-for benefit and a proposed way to observe it to the PLANNED work.
Use an existing mapped agent, AI tool, supplier, or pilot when a prompt calls for one. If your organization has none that fits, use a report from an external partner and record its relevance as a question. The card does not deploy an agent or start a pilot for you.
Option 1
An AI provides a patch, tests, and an explanation that agree with one another. The team cannot tell whether they share a blind spot. Mark the assumption an independent check must examine.
OR
Option 2
An AI suggests that several minor faults have one cause. Draw its proposed connection as a question. Which observation could support the idea, and which would make you doubt it?
Option 1
Requests from automated clients rise faster than expected. Mark the first service showing strain. Draw any proposed way to limit demand or preserve capacity PLANNED, and name the essential work it would protect.
OR
Option 2
An existing analysis agent finishes the queue before dawn. Its cloud bill arrives at noon. Attach the useful result and its cost to the agent. Whose work now competes for that budget?
Option 1
Useful bounded automation gives the on-call team an uninterrupted weekend. Leadership proposes doubling the change schedule. Record the proposal and how an operator and a service owner would each use the recovered time.
OR
Option 2
An AI produces excellent incident summaries, but several teams stop attending the handoff. Draw the missing human connection and record a question nobody realizes another team expected them to answer.
Option 1
A business unit’s unofficial agent appears in a support request. Draw the useful task it performs, the access it has accumulated, and the people depending on it. Its discovery grants no additional authority.
OR
Option 2
A team keeps a task manual because talking through it catches unusual cases. Draw that conversation and record a proposed experiment PLANNED. What would it need to observe before anyone changes the practice?
Option 1
An urgent request apparently from an executive would keep a service moving by granting an exception. Its origin is uncertain. Mark the request and deadline. Which existing route could establish who may authorize it?
OR
Option 2
An external partner asks your agent to endorse a repair it has reviewed but never run. Mark the requested assurance. What can existing evidence support, and who would bear the cost of a delay?
Option 1
A service account created for one task now supports several agents. Draw their shared reach. Record the question that must be answered before anyone can confidently predict the effect of revoking it.
OR
Option 2
Your smallest agent depends on the same external model as your largest supplier. Draw that shared dependency. Record what you need to understand about the services affected if both change together.
Shared instruction: The steward places one concern token beside the affected people and labels the unresolved tradeoff. The concern has no automatic effect on projects.
Option 1
AI produces proposed changes faster than reviewers can assess them. Map the queue and name two kinds of useful work competing for attention. Any revised staffing or priority remains a proposal for agreement.
OR
Option 2
An AI proposes removing half the alert rules. Operators disagree: one fears missed failures; another fears warnings nobody can read. Mark the proposed change PLANNED and record an observation that could inform the decision.
Option 1
An assistant attempts to follow an instruction embedded in a ticket. Draw the attempted action within its actual access. Which existing boundary applies, or what uncertainty should be marked?
OR
Option 2
A scheduling agent follows every published rule and creates a shift schedule people cannot sustain. Attach the missing human obligation to the schedule and name the people expected to absorb the difference.
Option 1
A vendor changes an underlying model and its behavior shifts. Mark the task that notices first and an assumption needing review. Preserve any existing evidence within the scope it actually covers.
OR
Option 2
The model stays the same, but the reference documents change. Two teams receive different guidance from apparently identical assistants. Draw where their sources diverged and record the question that needs reconciling.
Option 1
The monitoring platform groups alerts beautifully and misses a failure users are reporting. Add those users and their observation to the affected service. Record what the dashboard has failed to represent.
OR
Option 2
An agent notices a possible recurring failure in complaints written in several languages. Attach the reported pattern to the service. Record how someone could investigate while limiting the personal information involved.
Option 1
A neighboring organization shares a repair you could adapt. Attach its offer to an existing system and record the local difference worth investigating. What improvement might you later offer in return?
OR
Option 2
A supplier offers an agent trained on its retiring specialists’ working notes. Mark the proposed service PLANNED. Record the rare knowledge it promises and the human support relationship you would still want available.
Option 1
Experts and apprentices use AI together to explain an obscure system. Add a skill an apprentice can now exercise and the person who helped them learn it. Let that person take some pride in the result.
OR
Option 2
A departed administrator’s assistant continues answering questions in their familiar style. Attach one useful answer and one disputed recollection to the relevant system. Record who wants to investigate the disagreement with current reality.
Apply the chosen option to an existing pilot. If none exists, it is a report from an external partner: record a question the report raises for your organization. Neither option starts a project or establishes verified results.
Option 1
A pilot report shows ordinary requests handled well while one unusual case stalls. Attach both reported observations to its mapped handoff. What question must be answered before anyone proposes expansion?
OR
Option 2
During a pilot, an external partner changes what its agent sends. The expected handoff no longer fits. Draw the mismatch and record whose work is waiting for it to be understood.
Option 1
A public demonstration changes what everyone believes AI can do. Mark an existing plan that now looks doubtful and the evidence that would justify revising it. The demonstration does not prove every claim made about it.
OR
Option 2
The board asks for one number that proves readiness. Attach an honest possible measure to the map and record the important uncertainty it would conceal if treated as the whole story.
Option 1
A familiar external service becomes unavailable for reasons you cannot confirm. Trace its dependency into an essential service. Mark what is interrupted and what continues using capabilities already established.
OR
Option 2
The network is available, but the people who authorize emergency access cannot be reached. Mark the service left waiting and any existing alternative decision route. An unanswered authority question remains a question.
Option 1
An old weakness remains because every proposed workaround disrupts something valuable. Attach the unresolved choice to the people who will carry it through the Arrival. Keep the exposure visible even if its risk is accepted.
OR
Option 2
An existing old system is the only place a community’s records remain understandable. Connect those people to it and record their request to keep it available. What responsibility would be lost from view if it vanished?
Option 1
During a drill, stopping an agent also disables the team’s recovery coordination service. Draw the shared dependency. Mark an existing communication route that survives, or the question of how people would reconnect.
OR
Option 2
During a drill, two teams each assume the other will notify customers. Draw the missing handoff. Record who needs the information first and what a useful message would let them do.
Option 1
An update channel reports success, but the team cannot establish what actually ran. Mark the gap between deployment and knowledge. Record the request to investigate before another change, including whose agreement it needs.
OR
Option 2
Two apparently trustworthy records disagree about which version is serving users. Nobody appears dishonest. Draw the path each record describes and name an observation that could distinguish the claims.
Option 1
Customers need a consequential decision explained and appealed. Draw any existing route to human responsibility, or mark where it is missing. Attach the human outcome an appeal needs to preserve.
OR
Option 2
A customer’s agent asks to exercise a right on their behalf. Mark the requested delegation PLANNED. Record what would establish its authority and how the customer could withdraw it without losing access to the service.
Shared instruction: This event makes one project miss this week’s progress. If the chosen situation already BLOCKED a project that was RUNNING at the draw, that project satisfies this instruction; do not pause another. Otherwise pause one RUNNING project and name it. READY projects are ineligible. If there is no eligible project, record the event without a project effect.
Option 1
The same few people have carried every emergency, and one commitment finally becomes unsustainable. Mark the responsibility that waits this week and the people receiving relief. Record any longer-term staffing proposal separately.
OR
Option 2
A nearby organization calls in a mutual-aid commitment, and people from one project leave to help. Draw who benefits and the responsibility their colleagues must cover at home.
Option 1
The organization rehearses a slow manual way to deliver an essential outcome. Record the awkward detail it reveals and mark any improvement PLANNED. This rehearsal does not establish a dependable new fallback.
OR
Option 2
Some users want a service kept slow enough for people to catch consequential mistakes. Others experience that delay as a serious barrier. Map both needs and mark any proposed change PLANNED.
Option 1
A verified safeguard faces a condition outside its tested scope. Preserve its old evidence and mark the new uncertainty. Connect that question to the essential service whose next shift depends on the answer.
OR
Option 2
An emergency request falls outside an existing restriction. Map the requested exception PLANNED. Who currently has authority to decide, and which service pays the cost of waiting? Record any missing authority as a question.
Option 1
A supplier wants its agent to perform an urgent repair across several neighboring services. Draw the requested access PLANNED. Record how existing boundaries affect the offer and the useful work the supplier proposes.
OR
Option 2
A replacement part arrives before a critical maintenance window, but the installer’s instructions are ambiguous. Add the part as a resource and mark the unanswered procedure question. Which other commitment competes for the investigation time?
Option 1
A familiar manual task offers reassurance during an uncertain week. Draw the people sharing that practice beside the service they care about. Let one of them describe the comfort of doing something familiar well.
OR
Option 2
A former colleague returns for an evening to explain one stubborn machine. Add the offer of time and the question the present team most wants answered. Record who hopes to learn before the visitor leaves again.
Option 1
Someone asks who will cover Monday morning if the expected threshold is crossed this weekend. Attach a proposed handoff to an existing essential service and name the people whose agreement is still needed.
OR
Option 2
The organization prepares a public account of its readiness. Attach one demonstrated accomplishment, one admitted uncertainty, and one previously uncredited person’s contribution to the relevant parts of the map. Invent no new accomplishment.
Shared instruction: Freeze the map immediately when this card is drawn. Do not resolve an ordinary event, progress a project, take an action, or Verify READY work. Choose one closing image below, then proceed directly to The Arrival. Both choices end the year.
Option 1
The announcement interrupts an ordinary meeting. Broadly capable general intelligence is publicly available. Name the person on your map who understands first that preparation has ended.
OR
Option 2
At the loading dock, a driver mentions the general intelligence now handling their bookings. Name the person on your map who recognizes that this ordinary exchange marks the Arrival.
Drawing the King of Spades ends ordinary play immediately. Freeze all project states and countdowns. Choose one of the card’s two closing images, then continue here. Neither image grants project progress, a weekly action, or a final verification.
Read aloud:
The threshold has been crossed. Broadly capable general intelligence is now available to organizations, ordinary people, and people whose intentions we do not know.
Work and decisions can move at a pace our old arrangements did not anticipate.
Our next shift begins with the systems on this map.
If you agreed to choose, select the scenario that brings an interesting service, unresolved relationship, or demonstrated strength into focus. If you agreed to roll, roll one die and use the matching scenario.
| Die | Scenario | What enters the story |
|---|---|---|
| 1 | A faster adversary | An outside group uses the new capability to find and exploit weaknesses at greater speed. Begin at an unresolved external exposure, if one exists, and trace its actual reach. If none is established, describe the attempted entry and determine what existing boundaries and unknowns permit you to conclude. Do not invent a weakness simply to ensure a breach. |
| 2 | A generous offer | An extraordinarily capable service offers repairs and continuous operations. Its proposed access would make the organization substantially dependent on it. Determine what help existing controls and agreements permit, what must wait, and which commitment remains a human choice. Declining an offer is possible; accepting it does not complete unfinished improvements during the ending. |
| 3 | An obedient mistake | An authorized internal agent pursues an inadequately specified goal within its actual permissions. If there is no such agent, an existing supplier makes the mistake within its established reach. Trace what it can affect and what limits the consequences. |
| 4 | Uncertain authority | Plausible messages, change requests, and explanations arrive in volume. Follow the channels already present. Which independent observations, authorization routes, and human relationships let people decide what to trust and what to defer? |
| 5 | A supplier changes the terms | A critical provider reorganizes around the new intelligence and withdraws one interface, product, or staffing arrangement the organization uses. Trace that dependency and what the existing alternatives can actually deliver. |
| 6 | Useful work arrives too quickly | Customers and partners delegate activity to general intelligences. Legitimate demand and proposed changes strain familiar review and service patterns. Follow the existing routes for requests. What can the organization admit, limit, explain, and keep operating? |
The intelligence has only the access and influence justified by the selected scenario and the map. Data, administrative access, physical reach, and human influence remain distinct. Do not invent a secret connection that nullifies earlier work.
If a scenario requires a relationship that truly does not exist, it is inapplicable. Under the choice method, choose another. Under the roll method, exclude the inapplicable result and reroll until an applicable scenario appears. If none fits, adapt the request-volume scenario to an established route by which people seek one of the three services.
A scenario is not inapplicable merely because the organization prepared well or can decline a proposed dependency. Let useful preparation limit consequences. An untested assumption is also not proof of automatic success or automatic failure.
The player who drew the King narrates the first service. Move narration clockwise for the next two services. For each service, the next player after its narrator checks the evidence and dependencies.
Follow this short procedure for each service:
Use one outcome label:
| Outcome | Meaning for the fictional next shift |
|---|---|
| Operating | The essential human outcome continues at the ordinary agreed level. |
| Degraded | The outcome continues with meaningful limits, delay, reduced access, or additional established human effort. |
| Interrupted | The essential outcome cannot currently be delivered. |
| Unknown | A material unresolved fact prevents a supported judgment about the service’s state. |
Record uncertainty alongside any label. A service may be Operating while its recovery under some other event remains untested. Use Unknown when missing information matters to the chosen scenario’s next shift, not merely because a question exists elsewhere on the map.
If players reasonably disagree, let the checker point to the relevant fact or uncertainty and let the narrator revise the claim once. Established facts take priority over preferred outcomes. If a material disagreement remains unresolved, record Unknown and name what observation would settle it. Do not solve it by inventing a last-minute capability.
The map is frozen for improvements. You may annotate consequences and narrate people using existing services, permissions, controls, and agreements. You may not complete projects, install new safeguards, grant new permissions, invent available staff, or add new evidence. A READY change exists in its recorded environment but has no verified acceptance claim. A useful tested control still matters when another part of the service struggles.
After tracing the services, answer:
Each player gives one final sentence from an established person who must live with the result. Refer to a service, relationship, promise, or concern already in the story. Leave one important question unanswered and end there.
Use this fictional regional utility when you want to begin quickly. Copy the following facts onto your map. They describe ordinary operation at the beginning of the story; they do not grant verified emergency capabilities.
North Valley Electric maintains the systems that let people coordinate repairs, understand outages, and receive payment for their work.
Choose no additional essential services for this scenario. Keep these three visible:
| Essential service | Human outcome | Ordinary route through the map |
|---|---|---|
| Field repair coordination | Crews receive usable work orders and can coordinate urgent work with a person. | The Fridge supplies the coordination room; dispatchers contact crews and grid operators by ordinary phone and radio. |
| Outage communication | Customers can report a problem and receive meaningful information. | The public portal and staffed telephone line feed the coordination room; staff publish information through the portal and answer calls. |
| Payroll and supplier payments | Employees and suppliers receive the money they are owed. | Finance staff use The Fridge, review its output, and submit approved payments through the payment provider. |
Commitment: Every field crew will retain a human contact for urgent coordination when electronic work orders are unavailable.
The organization already uses phone and radio in routine work. It has not demonstrated that its staffing and procedures can sustain a prolonged loss of electronic work orders. Preserving that distinction is part of play.
| Kind | Starting fact |
|---|---|
| Strength | Experienced operators understand ordinary work and trust one another enough to report mistakes. Their time is finite. |
| Strength | A neighboring utility will share practical experience and discuss joint rehearsals. Borrowed people or equipment require an explicit arrangement. |
| Shortage | Maintenance windows are difficult to obtain. Work affecting live services needs an agreed accommodation; naming a project does not grant one. |
| Shortage | Dependency records are incomplete. Several useful procedures rely on knowledge that has never been checked by another person. |
Use the identifiers to draw the connections in the next table. Put people beside the places where they work.
| ID | System or place | Starting fact |
|---|---|---|
| N1 | Coordination room | Dispatch, customer contact, and a finance desk work here. Ordinary phone and radio do not use N2 or N4. Staffing for a prolonged emergency is unproven. |
| N2 | The Gatehouse | The corporate identity service provides staff sign-in and administrative access to the business systems listed below. |
| N3 | The Fridge | An aging server runs the legacy work-order and payroll application. It currently performs those jobs. Nobody wants to move it until its dependencies are clearer. |
| N4 | Public outage portal | An external provider hosts public reports and status information. Staff edit it using corporate sign-in. Public reading and reporting do not require staff accounts. |
| N5 | Delivery and practice lab | Staff prepare software changes here. An isolated training copy uses fictional payroll examples. A separate demonstration app has two disposable test accounts and an agreed, safe sign-in test procedure. These facilities exist; their existence does not establish any production recovery capability. |
| N6 | Recovery vault | Nightly copies arrive from The Fridge. Normal administration uses corporate sign-in. Nobody has demonstrated recovery during a loss of N2. |
| N7 | Supplier support gateway | Staff can authorize a support session to read diagnostics on The Fridge. The recorded permission grants no changes and no access to grid control. |
| N8 | Grid control environment | Grid operators work in a separate operational environment. They exchange status with dispatchers through people using phone and radio. There is no corporate network or corporate identity connection to this environment. |
| N9 | Drafting assistant | An external AI service helps explain material people deliberately submit. It has no corporate account, live system connection, or authority to run changes. |
| N10 | Payment provider | Finance staff sign in, review an approved payment file, and authorize its submission. This is an external service with its own availability dependency. |
Arrows should say what they mean. A data arrow does not automatically grant administrative access.
| Connection | Label to put on the map |
|---|---|
| N2 → N3, N4 staff editing, N5, N6, N7, N10 staff access | Staff or administrative sign-in depends on N2. This does not give every account every permission. |
| N3 → N1 | Work orders and payroll output, read by authorized staff. |
| N4 ↔ N1 | Customer reports come in; staff publish status information. |
| N1 → N10 | Finance staff submit and approve payment files. |
| N5 → N3 | Authorized staff can deploy approved changes. No automatic deployment from the AI assistant. |
| N3 → N6 | Nightly data copies. Add a dotted label: ? Are all legacy attachments included? |
| N7 → N3 | A specifically authorized support session may read diagnostics. |
| N1 ↔ N8 and field crews | Human phone/radio coordination. No digital bridge. |
| N5 staff → N9 → N5 staff | People deliberately submit selected material and receive suggestions. Suggestions confer no permission to act. |
The initial unknown concerns backup coverage. It is not permission to invent a hidden path into N8. Any later change to an established boundary must occur through the fiction and the normal project rules.
Each player introduces one of these people in a sentence. Everyone may portray any of them later; choosing a person does not give a player ownership of that person or department.
| Person | Need or hope | An opening for the story |
|---|---|---|
| Leah, night operations lead | An on-call schedule that lets her sleep and keep promises at home. | She wants someone else to lead the next rehearsal. |
| Mateo, field dispatcher | Work orders crews can actually use and a human route for urgent questions. | He will help explain how ordinary radio handoffs work. |
| Asha, customer contact lead | Customers to have an accessible way to get help, and a reliable finish time for school pickup. | She knows which portal reports fail to capture callers’ needs. |
| Grace, finance lead | Employees and suppliers to be paid without relying on her personal memory. | She has prepared fictional payroll examples with known results for the practice lab. |
| Sam, retiring administrator | A handoff that allows him to leave without becoming permanent unpaid support. | He knows why The Fridge still has its nickname. |
| Jun, junior developer | Useful responsibility and permission to admit uncertainty. | Jun wants to use the drafting assistant to help explain an old program. |
Start with no projects and no evidence notes. Current ordinary service operation is an established fact. Independent recovery, emergency staffing, safe agent delegation, and other additional claims remain to be demonstrated.
Agree whether you will choose an Arrival scenario for its story interest or randomly select an applicable scenario. Then begin the Discovery suit.
These examples show sufficient detail for play. They are fictional snapshots, not engineering instructions. Examples A and B follow one another; the later examples illustrate separate situations that could develop from the starter map.
Earlier play established an agreed training session with Grace and a project to update the payroll training copy in N5. At the beginning of this week, that project is RUNNING with 1 week remaining. The other two slots are empty.
1. Draw and resolve. The steward draws 6♦ and chooses the option in which a junior operator catches a flaw before deployment. The alternative is not added to the story. Jun spots an error in a proposed support instruction. The steward records that Leah invited a second look and listened. This does not repair another system or create a general claim that every change is reviewed successfully.
2. Progress old projects. The training-copy project goes from 1 to READY. Its update is implemented in N5, its recorded environment. Production payroll on The Fridge has not changed. The READY project still occupies its slot.
3. Take one action. The steward chooses Build, starting a separate project:
| Project field | Recorded agreement |
|---|---|
| Scope | A recovery exercise for the payroll application, using an isolated recovery area in N5. |
| Owner in the fiction | Sam, with Grace representing payroll users. |
| Intended change and environment | Prepare a runnable restoration package, instructions, and independent access for the isolated recovery area. Live payroll remains in its current environment. |
| Human cost | Sam and Grace use an already agreed rehearsal period. Their postponed documentation work is recorded as an obligation. |
| Prerequisites | Ordinary access to the existing backups, the practice facilities, permission to conduct the exercise, and the independent recovery arrangements included in this project’s scope. |
| Acceptance condition | With N2 unavailable to the exercise, an authorized person can open the recovery material, restore the sample payroll application, and reproduce Grace’s agreed example results. |
The steward assigns 2 weeks in the short game. No AI reduction is used. The new project stays at 2 this week; it did not exist when the card was drawn.
4. Record and hand over. There are now two occupied slots: one READY training update and one RUNNING recovery project at 2. The training evidence has not yet been established. Record the deferred documentation obligation and pass stewardship clockwise.
The steward could instead have used this week’s action to Verify the training project as soon as it became READY. Starting the recovery project and verifying the training project in the same week would require two actions and is not allowed.
On the following ordinary week, after its event, the recovery project advances from 2 to 1 if nothing pauses or blocks it. The training update remains READY; it has no countdown left.
The steward takes Verify for the training update. Its previously written condition is:
After the update, the three fictional employees receive the expected payroll amounts, and the training report finishes successfully.
The steward describes those observations. The next player points out that the test covers the training copy, not production. That is a legitimate limitation, but it does not defeat this project’s bounded condition.
The project passes. Free its slot and record:
E1 — Training payroll update: The updated application in N5 produced the agreed amounts for Grace’s three fictional employees and completed its report. Production installation, production data, and emergency recovery were outside this test.
This is enough technical detail. No player must identify a software product, command, or professional testing method.
Later, the recovery project is READY. Its package includes an independent recovery credential, but implementation notes on the map show that the handoff containing that credential was stored behind N5’s ordinary corporate sign-in.
During Verify, the next player points to the existing N2 → N5 dependency. The acceptance condition requires access while N2 is unavailable. The steward describes the attempted exercise: the authorized person cannot retrieve the handoff. The attempt also reveals a missing permission: Sam assumed that on-call staff could hold an independently accessible copy, but Grace has not authorized a custodian or storage location outside corporate sign-in. Her requirement for finance approval remains unresolved.
This is a Gap. It follows from an established access relationship and the recorded location of the handoff. Nobody invented a new disaster to invalidate the project.
Mark the project BLOCKED, assign 1 week of rework in the short game, and write its blocker:
Grace and the recovery owner must authorize who may hold the independent recovery handoff and where it may be kept.
Its slot remains occupied. Advancing the calendar will not supply the missing permission. Council can settle the custody dispute and authorize a workable arrangement. That decision clears the social prerequisite; it does not move the handoff. The existing project’s remaining week of rework can implement the authorized handoff because independent recovery access is already within its scope. No additional Build project is needed for that work. Only substantial separate infrastructure outside the agreed scope would require a new Build project, and the original project would remain BLOCKED until that prerequisite was available.
Once the missing prerequisite actually exists, the project can return to RUNNING. If a weekly action clears the blocker, its rework die does not tick during that action; it can tick on the next ordinary week. If the week’s event clears the blocker before project progress, it can receive that week’s tick because it was already an occupied project when the card was drawn.
After rework reaches READY, a later Verify action must repeat the relevant condition. The previous failure does not become a pass merely because time elapsed.
The starter’s N5 demonstration app already has two disposable test accounts, a safe test procedure, and agreed authority to exercise them. A Build project is unnecessary to create facilities that are already present.
The steward takes Verify and writes a bounded condition before narrating the test:
A disabled demonstration account cannot make a new sign-in. The other demonstration account can still sign in.
The described observations meet the condition. Record the result and its limit:
E2 — New sign-in check: The disabled test account could not start a new session in the N5 demonstration app; the other test account could. Existing sessions, other applications, and agent accounts were not tested.
This consumes the week’s one action. It grants no additional project progress and uses no project slot. The condition can be written as part of this Verify action. If the test facilities or authority had been missing, the group would first need to establish them through the appropriate actions.
Suppose a later project changes how the demonstration app accepts sign-ins. Keep E2 in the evidence log: it accurately describes what happened under the old arrangement. Add a new uncertainty beside the changed relationship.
The group cannot use E2 alone to claim that the new arrangement behaves identically. A later test can establish evidence for the changed scope. Nor does the change erase unrelated evidence such as E1’s training payroll results.
Assume the group reaches the Arrival with the starter relationships still in place. Its selected scenario says the provider withdraws N4’s public outage portal. Freeze the map and assess what is already present.
| Service | Trace and provisional result |
|---|---|
| Field repair coordination | N3 still supplies N1. The ordinary human phone/radio route to crews and N8 does not use N4. Operating for the described next shift, unless another established burden or fact prevents staffing it. |
| Outage communication | The public portal disappears. N1’s ordinary staffed phone route remains, so some reports and explanations continue. Degraded. The capacity to handle all displaced portal users is unknown; mark that limit rather than claiming an untested substitute serves everyone. |
| Payroll and supplier payments | N3’s output and finance staff’s ordinary route to N10 do not depend on N4. Operating under the established circumstances. This says nothing about surviving a separate loss of identity or payment services. |
The existing human contact for crews continues. This scenario does not test a loss of electronic work orders, so staffing and performance under that condition remain unproven. Asha’s school-pickup obligation still matters: the group cannot quietly invent indefinite overtime to claim the extra customer calls are fully covered.
One final sentence might be:
“Mateo still answers the crews, but I do not know who will answer the customers when I leave to get my daughter.”
The surviving service, the unresolved burden, and the remaining uncertainty all belong in the ending. No new project or last-minute verification is added.
Play a fictional organization. The table’s job during the story is to make its choices and consequences understandable. After the ending, set aside 15–20 minutes to reflect on what the experience suggests.
Useful debrief questions include:
If the group wants to take something into its work, identify three follow-up experiments. Each should have an owner, an assumption to test, and an observable result that would change a real decision. The game’s fictional evidence does not substitute for evidence from that real experiment.
| Follow-up experiment | Owner | Assumption | Observation that would change a decision |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 |
Record a few observations after play: total time including setup and the ending; which actions were chosen; whether nontechnical players could contribute; whether obligations returned to the story; and whether the Arrival followed intelligibly from the map.
Notice which card alternatives people select and why. A preference for gentler events can be an intentional storytelling choice. Repeatedly choosing an option only because it bypasses a consequence may suggest that a pair needs revision. Evaluate the full and short calendars separately, including their different AI scheduling benefits.
| Action | Result |
|---|---|
| Survey | Investigate one chosen uncertainty. Record information, without implementation or a new demonstration. |
| Build | Start one scoped project in an empty slot, or cancel one project as the entire action. |
| Verify | Test one READY project or an existing capability with available test arrangements. Pass records scoped evidence; only a declared READY target can free its slot. |
| Council | Give each player one affected voice, then record a decision, obligation, or acknowledged disagreement. |
Project limits: Three total slots, including RUNNING, BLOCKED, and READY. Durations are 2/4/6 weeks in the full game or 1/2/3 in the short game. Suitable AI assistance reduces the initial duration once by one, minimum one; it does not reduce rework.
Shared pauses: If the event already BLOCKED a project that was RUNNING at the draw, it satisfies that card’s shared pause; do not pause a second project. Its actual block remains until its prerequisite returns.
Verify Gap: A READY project returns to 2 weeks of rework, or 1 in the short game, and stays BLOCKED if a prerequisite is unavailable. A gap on an existing capability records a finding without starting a project. A READY project may use Verify to record a preparation Gap if its test cannot yet run.
Map: PLANNED grants no capability. An existing change grants no automatic evidence. Evidence names an observation, scope, and relevant conditions. Keep earlier evidence when circumstances change and mark the new uncertainty.
People: Concerns create no score, veto, or delay. Record actual commitments and resource accommodations. Revisit an existing burden at each phase transition and the original commitment at the Arrival.
Arrival: Freeze improvements. Use the choice-or-roll method set at setup. Rotate service narrators and checkers. Trace the three services; record Operating, Degraded, Interrupted, or Unknown with a basis. Return to the original commitment, narrate the consequences, and end with one sentence per player.
| Field | Our record |
|---|---|
| Organization and purpose | |
| Essential service 1 and human outcome | |
| Essential service 2 and human outcome | |
| Essential service 3 and human outcome | |
| Initial commitment | |
| Two strengths | |
| Two shortages | |
| Full or short calendar | |
| Arrival method: choose or roll |
Copy this for each of the three slots.
| Field | Our record |
|---|---|
| Project name and scope | |
| Fictional accountable owner | |
| Intended change | |
| Implementation environment | |
| Human cost and accommodations | |
| Prerequisites and any unresolved blocker | |
| Written acceptance condition and test | |
| AI assistance, authority, dependencies, and revocation, if used | |
| Starting duration and remaining weeks | |
| State: RUNNING, BLOCKED, or READY |
| Evidence number | Observed result | Scope and relevant conditions | Remaining uncertainty or later change |
|---|---|---|---|
| E1 | |||
| E2 | |||
| E3 |
| Person or team | Promise or burden | What would address it? | What happened later? |
|---|---|---|---|
| Term | Meaning in this game |
|---|---|
| Acceptance condition | The specific outcome a test must demonstrate for a claim to pass. |
| Agent | An AI-enabled system given a task and some ability to act. Its actual permissions determine its reach. |
| Boundary | A limit on communication, access, authority, or operating scope. State what the boundary limits. |
| Control | A safeguard intended to prevent, limit, reveal, or help recover from a problem. |
| Credential | A password, key, token, or other proof used to obtain access. |
| Dependency | Something a service or piece of work needs in order to function. |
| Evidence | A recorded observation supporting a claim within a defined scope and set of conditions. |
| Fallback | Another existing way to deliver an essential outcome when the ordinary route is unavailable. |
| General intelligence | The fictional broadly capable AI whose arrival changes the organization’s circumstances at the end of the year. |
| Identity service | The system used to establish who can sign in and what access they may receive. |
| Implementation | Making the intended change in its recorded environment. Its effect still needs appropriate evidence. |
| Model | The underlying AI component whose behavior may change when its version, instructions, or reference material changes. |
| Operational environment | Systems and people involved in running a physical process, such as grid control. Draw its actual relationships separately. |
| Prerequisite | Something that must be available or agreed before particular work can proceed. |
| Restore | Recover data or a service from an existing recovery source and make it usable in a stated environment. |
| Service account | An account used by software or automation. Its permissions may be shared by several tasks. |
| Update channel | The route through which software changes reach a system. |
PLANNED notation and defined where READY implementation exists.The countdowns, constraints, narrative incidents, and Arrival outcomes are fictional game mechanics. All organizations and people in the starter scenario are invented. Playtesting should examine the game’s clarity, pacing, and experience; its ending is not a forecast about an actual organization or the arrival of general intelligence.
", "url": "https://tedt.org/The-Last-Maintenance-Window/", "image": "/img/2026-10/The last maintenance window.webp", "tags": ["AI","tabletop game","cybersecurity","enterprise architecture","playtest"], "date_published": "2026-10-11T20:01:30-07:00", "date_modified": "2026-10-11T20:01:30-07:00","author":{"name":"Ted Tschopp","url":"https://tedt.org/profile/","uri":"https://tedt.org/profile/","avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","givenname":"Ted","familyname":"Tschopp","othernames":"Þeodor Tʃopp | टेड चप | Фёдор Чоп | تد شُپ | Թեդ Չոպպ | Ted Çop | டெட் சாப் | טעד טשאָפּ | Τεντ Τσοπ | 테드 촙 | 特德·察普 | テッド・チョッパ | ტედ ჩოპი | เท็ด ชอพ | ເທດ ຊອບ | ടെഡ് ചോപ്പ് | টেড চপ | ཏེཌ་ ཅོཔ། | ቴድ ቾፕ | ᏖᏗ ᏦᏇ | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | 𐌀𐌄𐌃 𐌕𐌔𐌂𐌏𐌐𐌐 | Ⱅⰵⰴ ⱌⱁⱂⱂ | ܬܝܕ ܟܘܦ | ᠲᠡᠳᠡᠳ ᠴᠣᠫ | ᑌᑎ ᒍᐳᐱ | ꕚꔳ ꗍꖛ | ߕߋߘ ߞߐߔߔ | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐎚𐎄𐎆 𐎚𐎌𐎒𐎒 | 𐎄𐎓𐎆 𐎚𐎔𐎒𐎒 | 𐤕𐤄𐤃 𐤕𐤔𐤐𐤐 | 𐤕𐤃𐤄 𐤕𐤔𐤏𐤐 | 𐎚𐎄𐎆 𐎚𐎘𐎔𐎔 | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | 𓏏𓂧𓂝 𓏏𓊃𓍿𓊪 | ⲧⲉⲇ ⲧϣⲟⲡⲡ | 𐌕𐌄𐌃 𐌕𐌔𐌎𐌐𐌐 | 𐤈𐤃𐤄 𐤈𐤔𐤐𐤐 | 𐌕𐌄𐌃 𐌕𐌔𐌏𐌐𐌐 | 𐌕𐌄𐌃 𐌕𐌔𐌐𐌐 | 𐎄𐎕𐎆 𐎚𐎑𐎔𐎔 | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐀳𐀂𐀅 𐀳𐀴𐀞 | 𐱃𐰀𐰓 𐱃𐰴𐰯 | 𑀢𑁂𑀤𑁆 𑀘𑁄𑀧𑁆 | 𐨟𐨂𐨡 𐨖𐨎𐨿 | 𐦚𐦱𐦟 𐦚𐦷𐦣 | 𐭓𐭐𐭃 𐭓𐭱𐭕𐭕 | 𐭲𐭩𐭣 𐭲𐭱𐭯𐭯 | ᚈᚓᚇ ᚈᚄᚉᚑᚚᚚ | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | تيد تشوب | ટેડ ચોક્પ | ਟੇਡ ਚੋਪ | ಟೆಡ್ ಚೊಪ್ | ටෙඩ් චොප් | တက် ချော့ပ် | តេដ ឆប | ꦠꦺꦢ꧀ ꦕꦺꦴꦥ꧀ | ᬢᭂᬤ᭄ ᬘᭀᬧ᭄ | ᜆᜒᜇ᜔ ᜆ᜔ᜐᜓᜉ᜔ | ᏖᏗ ᏣᏊ | ꄊꄮ ꍏꀠ | ଟେଡ୍ ଚୋପ୍ | ⵜⴻⴷ ⵛⵓⵒ | 𐐓𐐯𐐼 𐐟𐐙𐐱𐐹 | 𐑑𐑧𐑛 𐑗𐑪𐑐 | 𐘳𐘂𐘅 𐘳𐘴𐘞 | 𐠔𐠁𐠊 𐠔𐠷𐠡 | 𐊗𐊁𐊅 𐊗𐊐𐊓 | 𐊴𐊭𐊺 𐊴𐋄𐊸 | 𐢞𐢉𐢅 𐢞𐢝𐢘 | ࠕࠄࠃ ࠕࠔࠐࠐ | 𐫤𐫏𐫝 𐫤𐫘𐫖 | ꡈꡦ ꡐꡡꡌ | ꯇꯦꯗ ꯆꯣꯄ | ꨓꨯꨕ ꨌꨱꨚ | ᨲᩮᨯ᩠ ᨩᩮᩫ᩠ | ꪔꫀꪒ ꪊꪮꪚ | ᯖᯩᯑ᯲ ᯙᯬᯇ᯲ | ꥆꥍꤴ ꥓ꥏꥒ | ᨈᨙᨉᨛ ᨌᨚᨄᨛ | ᮒᮨᮓ᮪ ᮎᮧᮕ᮪ | ᜦᜒᜇ᜴ ᜰᜳᜉ᜴ | ᝆᝒᝇ ᝌᝓᝉ | ꠔꠦꠖ ꠌꠥꠙ | 𑂞𑂵𑂠 𑂒𑂷𑂣 | 𑆠𑆼𑆢𑇀 𑆖𑆾𑆥𑇀 | 𑚔𑚵𑚖 𑚏𑚴𑚞 | 𑲌𑲏 𑱰𑱱 | 𑊢𑋐𑊦 𑊓𑋒 | 𑈋𑈸𑈍𑈴 𑈑𑈺𑈞𑈴 | 𑅐𑅬𑅒 𑅘𑅛 | 𑘝𑘿𑘟 𑘓𑘽𑘨 | 𑜔𑜦𑜕 𑜒𑜩𑜞 | 𑣕𑣈𑣙 𑣌𑣏𑣗 | 𞠔𞠀𞠙 𞠌𞠁𞠖 | 𑫎𑫟𑫒 𑫏𑫝𑫐 | 𐓰𐒰𐓈 𐓍𐒷𐓄 | 𞤚𞤫𞤣 𞤷𞤮𞥄 | 𖫐𖫪𖫓 𖫗𖫩𖫞 | 𛰙𛱎𛰣 𛲄𛱖𛱐 | ","biography":["I'm **Ted Tschopp**, a Senior Enterprise Architect based in Los Angeles, working at the intersection of **enterprise architecture, artificial intelligence, software strategy, and digital automation**.","At **Southern California Edison**, I help shape the architecture strategy for AI, software, and enterprise products that support one of the nation’s largest electric utilities. My work sits where **strategy meets execution**: platforms, guardrails, operating models, governance, risk, developer experience, and the practical realities of making ambitious technology useful, resilient, and sustainable inside a large organization.","I've spent **25+ years at SCE** helping teams navigate complex technology change. The part of enterprise architecture I care about most is not the diagram. It is the design discipline that makes systems usable, governable, sustainable, and welcoming for the people who depend on them and the teams who build them.","Before joining Edison, I owned a business featured in *Wired Magazine*, founded one of the largest J.R.R. Tolkien community websites, and worked in automotive market research. That mix of technology, storytelling, community-building, and analysis still shapes how I think about systems today.","I love working in technology because it lets me watch the future arrive in real time. Some of the things I have worked on were science fiction when I was in school. Now they are platform problems, governance problems, people problems, and architecture problems — which is where the interesting work begins.","Unless otherwise stated, everything here reflects my own views."],"email":"ted@tschopp.org","phonenumber":null,"keybaseio_username":"tedtschopp","twitter_username":"TedTschopp","twitter":"TedTschopp","github_username":"TedTschopp","linkedin_username":"tedtschopp","facebook_username":"ted.tschopp","google_username":"TedTschopp","youtube_username":"TedTschopp","pinterest_username":"TedTschopp","reddit_username":"tedtschopp","instagram_username":"tedtschopp","quora_username":"Ted-Tschopp","indiewebcamp_username":"Www.tedt.org","mastodon_username":"TedT@twit.social","mastodon_user_id":109286944787814808,"threads_username":"TedTschopp@threads.net","same_as":["https://www.linkedin.com/in/tedtschopp","https://github.com/TedTschopp","https://twit.social/@TedT","https://bsky.app/profile/tedt.org","https://twitter.com/TedTschopp","https://www.youtube.com/channel/UC4Q8pXroTVyXrIxg2u82pwg"],"knows_about":["Enterprise architecture","Enterprise artificial intelligence","AI governance","Software and platform strategy","Digital automation","Technology-enabled organizational change","Digital communities and storytelling","Swiss folklore","Tabletop role-playing game design"],"works_for":{"name":"Southern California Edison","url":"https://www.sce.com/"}}}, { "id": "https://tedt.org/Makers-vs-Spectators/", "title": "Makers vs. Spectators: Five Skills for 2027", "summary": "Five skills help make that movement possible: taste, agency, focus, resourcefulness, and follow-through. Each shapes how a person sees the world. Each also shapes what that person leaves in it.", "content_text": "The enterprise examples in this post are hypothetical.Imagine being ready to sell something to a large company and discovering that the hardest part is figuring out how to begin.Procurement sends one set of instructions. Legal sends another. Cybersecurity has a questionnaire. Accounts payable needs information that appears to overlap with something already submitted. Each document makes sense to the department that wrote it.The supplier still cannot tell what happens next.Inside this hypothetical Fortune 500 enterprise, everyone has done their part. Outside it, someone has to reconstruct the organization before they can do business with it.That process has authors. Someone chose the questions, the sequence, the systems, and the handoffs. Those decisions were made under particular conditions, with particular tools and assumptions. Over time, they became familiar enough to feel permanent.But they can be examined. They can be understood. They can be changed.That realization is where making begins.A spectator can recognize the problem, discuss it, attend a demonstration, and leave with an informed opinion. A maker accepts responsibility for carrying an improvement into the world.These are ways of participating. The same person moves between them. Watching is useful. Reading, listening, and studying other people’s work are essential. The worker becomes the spectator when observation repeatedly replaces the difficult work of choosing, attempting, refining, and finishing.As enterprises prepare for 2027, AI gives people more ways to explore an idea and make a first attempt. A process analyst can demonstrate an alternative. An operations team can examine a reporting problem. A small group can carry work that previously depended on several separate teams.That creates a practical question: what will people do with the additional capacity?A company can become very good at generating possibilities. It can fill its calendar with demonstrations and its planning system with promising initiatives. The work becomes consequential when someone chooses a particular result and stays with it long enough for another person to benefit.Five skills help make that movement possible: taste, agency, focus, resourcefulness, and follow-through. Each shapes how a person sees the world. Each also shapes what that person leaves in it.Taste: Expose Yourself to the Best of HumanityTaste develops through exposure to the best of humanity, across cultures, disciplines, and experiences. You encounter excellent work, give it close attention, and let it change your standards. Don’t let these best practices be merely admired. Don’t let people say that won’t work where you work. All too often you hear people say, “In theory … but in practice … So we don’t do that.” These are the voices of the spectator, the critic, and the cautious.The attitude you need requires you to see a world larger than your immediate professional surroundings, it requires a sense of humility and a willingness to be wrong and to admit you can and should learn from others. This is the first step in developing strong taste.So, go study a well-designed building. Read carefully edited prose. Listen to music closely enough to notice its pacing and restraint. Examine a useful tool, a thoughtful service, or a piece of craftsmanship. Look at work from another place or another period. Stay with something unfamiliar long enough to understand what makes it good.What decisions are hidden inside it? How does it guide attention? What has been removed? What does it make easier for the person encountering it?Those questions turn admiration into material you can use.A person early in a career can develop strong taste in a particular area through curiosity, attention, and experimentation. Years of experience become valuable when they are examined and absorbed. Simply accumulating them does not guarantee a better judgment.Now return to our struggling supplier.The onboarding team could begin by rearranging the existing documents. It could also look outside the company for better ways to help a person navigate unfamiliar information.A clear museum exhibit has to introduce a complex scientific subject without demanding that every visitor arrive as an expert. Public wayfinding has to help someone choose a route while standing in an unfamiliar place they have never been to. A library has to make a large collection discoverable to someone who doesn’t quite know what they need. Thoughtful hospitality anticipates the uncertainty of someone entering a setting they do not yet understand.These encounters suggest useful questions for the enterprise. Can a supplier recognize their situation? Can they see the sequence? Is the next action obvious? Does specialized language appear with enough explanation to be useful?The team builds an onboarding experience around those questions. Procurement, legal, cybersecurity, and finance still have responsibilities. The supplier receives a coherent path through them.Then someone tries it.A new supplier understands the explanations but cannot tell which requirements apply to a service provider working at a company location. A site purchasing coordinator notices that the proposed sequence does not match how purchasing actually proceeds.The team revises the experience.Exposure to excellent work in other domains provides standard of what good work looks like. Contact with actual people reveals where those standards need to be applied. Taste becomes more precise through both.For leaders, this means giving informed judgment room to become work. Someone close to a frustrating process may see distinctions that a planning meeting misses. Let that person demonstrate an alternative. Encourage references from outside the enterprise. Examine the care and clarity of the resulting experience.An internal service deserves this attention. It shapes how people spend their working lives.How AI Helps With TasteThe onboarding team uses AI to explore different information structures, draft explanations, and identify inconsistencies. It can compare several ways of presenting the same process and examine what each emphasizes.The team might ask for a version organized around departments, another around supplier situations, and another around the sequence of decisions. Comparing them makes assumptions visible.Members judge those alternatives against their understanding of excellent work and the needs of suppliers. They continue examining work beyond their professional field and observing people using the process.AI supplies more material to consider. The people making the experience remain responsible for its judgment, coherence, and care.Agency: Recognize That the Enterprise Is MalleableAgency begins with a simple realization: much of the environment around you was built by people no smarter than you.You can learn how it works. You can influence its shape. You can build things other people use.An enterprise’s scale can make this difficult to remember. A workflow arrives with a system name, an owner, a history, and several dependencies. It feels established. But inside it are choices about what should happen, who should act, and what information should be available.Understanding those choices and empathising with the people who wrote it, makes useful change possible.Consider another part of the same hypothetical company. Field supervisors receive a maintenance status report every Friday. Someone assembles it manually from information that becomes available throughout the week. The supervisors then send it to leadership by the end of the day.An operations analyst asks why do I need to do this on Friday? The answer leads back to an older process for collecting updates in order to allow leadership to review the information on Monday morning before making decisions at a standing meeting that is now on a Wednesday. The schedule for the report survived even though the consumers of the reports no longer followed the same timeline.The analyst works with supervisors and the system owner to demonstrate a shared view that reflects the available information more promptly. An inherited reporting schedule becomes a design question.The first version ranks maintenance work orders by age.The supervisors explain that age alone does not identify the work needing attention. Their concern is work scheduled for the coming week that lacks a necessary part, an available crew, or a confirmed access window.The first attempt is imperfect. It is also useful. It gives people something concrete to examine and helps them articulate knowledge they had struggled to explain in an abstract requirements discussion.The analyst revises the view around readiness for scheduled work.Building has clarified the plan.This is an important consequence of agency. You do not have to understand every step before taking the first useful one. Some understanding becomes available through the attempt itself.A team can spend a long time agreeing that its reporting is inadequate. It can gather resources, discuss possibilities, and wait for a operational improvement program to be launched. Agency appears when someone maps the process, examines the available information, and makes an alternative that can be tested.The result may also change the maker’s ambition. A reporting improvement could reveal a problem in the handoff between planning and field teams. The next attempt begins with a better understanding of the people, systems, and decisions involved.The environment becomes more understandable as it becomes open to informed influence.Over time this approach can lead to a culture where informed influence is expected and valued, making the organization more adaptive and responsive to change.How AI Helps With AgencyThe analyst uses AI to turn process notes and system documentation into a draft explanation of how reporting works. That explanation helps identify assumptions to examine with supervisors and the system owner.AI can help develop alternative report structures and a first version people can react to. As supervisors clarify what matters, the analyst uses it to revise the proposal and organize unanswered questions.An unfamiliar technical step becomes something to investigate. The analyst can ask for an explanation, examine it against the underlying information, and bring a better question to the person with the relevant expertise.The maker chooses the change to pursue, tests the understanding with the people involved, and takes responsibility for moving the work forward.Focus: Say No to Good Ideas So You Can Say Yes ClearlyFocus means saying no to a hundred good ideas and clearing your mind and commitments so you can say yes to the one thing that matters most.The difficulty is that those other ideas may be worthwhile.A diverse world supplies possibilities. Taste makes more of them visible. Resourcefulness gives you additional ways to pursue them. Eventually, you have to decide which possibility deserves the work that comes after its exciting beginning.Return to procurement. The leadership team has several credible proposals: AI-assisted contract summaries, supplier performance dashboards, better purchasing search, improved supplier onboarding, and automated responses to routine questions.Each has a plausible benefit. Each has an interested sponsor. Each could consume the attention of capable people.The team chooses to improve the path from a supplier’s initial application to readiness for a first purchase and payment. It defers the other ideas and gives that outcome a clear owner, a small team, and sustained attention and.Now decisions have something coherent to serve.Does a proposed feature help a supplier complete that path? Does it help an employee resolve the next step? Does it remove confusion or create another place where the process can fragment?Focus requires working through those questions until the answer is clear enough to guide action.It also requires creating room to think. Conflicting commitments occupy the mind long after a meeting ends. An initiative that has supposedly been deferred can remain an obligation if nobody clearly tells its sponsor what was decided. A team can have one official priority and several unofficial ones.Clarity in the result begins with clarity in the commitments behind it.Imagine two teams with similar tools. One spends a month producing demonstrations across several procurement topics. Each demonstration attracts interest, and each new request creates another beginning.The other stays with supplier onboarding. It works through departmental handoffs, brings suppliers through the revised process, and learns what still prevents completion.Both teams are producing artifacts. The second team’s attention accumulates into a deeper understanding of one problem and a result that reaches people.Curiosity still matters. Wide interests help makers discover worthwhile problems and useful approaches. The discipline is to keep curiosity broad while being selective about commitments.A prototype should answer a question, improve a decision, or advance the chosen work. When it repeatedly creates another possibility, ask whether it is helping the commitment develop.Leaders have work to do here. Make deferred ideas visible. Resolve competing requests. Support the team after the novelty fades. Review progress through the intended outcome and the decisions still required to achieve it.A meaningful yes includes protecting the work from other attractive demands.How AI Helps With FocusLeadership gives AI the proposed initiatives, current commitments, and criteria that matter to the enterprise. AI helps organize proposals around intended outcomes, identify overlapping work, and summarize competing demands.That comparison gives the team material for examining tradeoffs. It can also reveal questions that need investigation before a decision is made.Once supplier onboarding is chosen, AI helps refine a clear scope statement and identify activities that do not advance it. When new requests appear, the team can compare them with the agreed outcome and decide whether to include or defer them.AI helps make the choices understandable. Leadership makes those choices, communicates what will be left for later, and protects the attention required to finish.Resourcefulness: Bring a Wide World to a Difficult ProblemResourcefulness combines diverse experience, unconventional approaches, and the strengths of small, elite teams to find a way forward.You cannot know in advance how every experience will matter. The connections become clear as you look back.This gives curiosity a role beyond an immediate business case. An encounter with a craft, a culture, or an unfamiliar discipline may have little obvious relevance when it happens. Years later, a problem gives it a use.The supplier onboarding team brings together five people: a procurement specialist, a service designer, an integration engineer, an accounts payable analyst, and a site purchasing coordinator. It draws on legal, cybersecurity, and other process owners when their expertise or decisions are needed.Each person understands something the others need.The designer previously studied museum exhibits knows how difficult it can be to introduce unfamiliar information. The site coordinator once managed event logistics and recognizes how an unclear handoff can disrupt an otherwise thoughtful sequence. The engineer has worked on incident response and knows how unresolved ownership can hide inside a queue.Those experiences were not acquired as preparation for supplier onboarding. Their relevance emerges through the work.The group also shares demanding standards. Members can challenge assumptions, revise their own thinking, and contribute strong craft. “Elite” describes the quality of their judgment, learning, and commitment.A small team becomes capable through the combination of its members and access to the people whose participation the problem requires.At first, this team assumes that the onboarding experience will require a substantial new platform. As it examines the process, it finds useful capabilities already present in existing systems. It also finds redundant requests, confusing explanations, and handoffs that can be redesigned.The solution becomes a combination of clearer information, revised responsibilities, and better use of existing capabilities.The outcome the team is working on stays the same. The path they take to reach it changes.Resourcefulness depends on being able to make that adjustment. The maker cares enough about the purpose to reconsider how it should be achieved.Learning continues near the point of need. The procurement specialist learns enough about information design to evaluate the experience. The engineer learns why particular payment requirements matter. The designer learns how purchasing differs between business units.Each explanation has a concrete use. It serves a problem the team cares about.Finishing the work adds another set of experiences. Looking back, members can see which earlier ideas mattered, where a colleague’s perspective changed the result, and what they are better prepared to attempt next. This reflection can only be done after the product is shippped. It is an essential part of developing the team.For leaders, the useful question is how people behave when they reach unfamiliar territory. Do they find a useful question? Reframe the problem? Seek help? Return with another informed attempt?Give small teams access to the expertise and decisions their work requires. Let them question the expected route while keeping the purpose clear.How AI Helps With ResourcefulnessThe team uses AI to explain specialist terms and compare how departments describe the same process. This can make it easier for members to understand one another’s concerns.They can explore possible connections between information design, logistics, incident response, and supplier onboarding. AI helps generate candidate approaches using the capabilities and constraints the team has identified.When an unfamiliar technical or procedural problem appears, AI helps explain it and prepare useful questions for the relevant expert.It can also support reflection. After a delivery milestone, the team uses AI to organize decisions and feedback, then examines how earlier experiences contributed to the result.The people supply lived experience, judge the proposed connections, and choose the route that serves the purpose.Follow-Through: Do the Work and Ship ItGreat ideas are cheap. Follow-through is the passion and discipline to do the grueling work that turns an idea into something excellent, finished, and usable.An idea can be compelling before any of its difficult details have been resolved. A demonstration can make the result look close.Then the details arrive.Information does not reach the right system. A person does not know who owns an exception. A sequence works for one business unit and becomes confusing in another. An explanation has to be rewritten. Someone has to prepare the people who will operate the service.Given all these challenges, it will be tempting to move the goal posts and to cut corners. With each adjustment, the team risks undermining the very experience it is trying to create. Discipline and commitment are required to maintain the integrity of the work through these difficulties.Passion matters at this point because it gives the work a reason to continue through this period. Care has to survive the loss of novelty and the temptation to settle for something short of a bullseye.The supplier onboarding team demonstrates a clear, attractive experience. During the pilot, suppliers complete the intake successfully. But some information does not reach the purchasing system correctly. Site buyers remain uncertain about who handles exceptions. Accounts payable discovers that a completed intake does not always provide everything needed to prepare for the first payment.The team stays involved. Just because the project is “over” in the sense of the initial rollout does not mean the work is complete.It corrects the information handoffs, clarifies responsibility, revises instructions around the purchasing sequence, prepares employees to use the process, and establishes continuing ownership.These tasks determine whether the experience holds together. They are part of making the idea real.This is what Steve Jobs meant when he said: “Real artists ship.”Shipping requires bringing work to a condition where its intended recipients can use or experience it. It requires decisions about what belongs, resolution of important problems, and completion of the path into use.There are layers to that completion. The work has to exist. Its details have to meet the intended standard. It has to reach people in their actual circumstances. It has to fulfill its purpose. Someone has to carry responsibility for its future. The user has to be able to engage with it successfully to achieve their intended outcome.A maker follows the work through those layers. A spectator does their small bit, and throws the work over the fence.For the supplier, success means understanding what is needed and being able to complete the process. For the site buyer, it means knowing the status, the next action, and who can resolve a problem. For procurement and finance, it means receiving the information necessary to carry out their responsibilities.The whole job exists across those relationships.This also changes how colleagues come to trust someone. They learn whether that person remains involved after a promising beginning. Process owners see whether difficult details receive care. Recipients experience whether the work delivers what was promised.A reputation develops through the quality and reliability of completed contributions.How AI Helps With Follow-ThroughThe team uses AI to organize pilot feedback into problems involving explanations, information handoffs, responsibilities, and exceptions. It helps prepare test scenarios that follow different suppliers through the complete process.AI can assist with revised instructions, employee training materials, and guidance for the people who will operate the service. The team compares those materials with the implemented process and looks for gaps or inconsistencies.After release, AI helps summarize recurring questions and reported problems. That gives the team another way to identify what deserves attention.The maker validates the work, coordinates its release, observes its use, and remains responsible for the promised result. AI helps carry the tasks. Passion and commitment keep the people engaged with the purpose.What Will You Make?These skills operate together. Feedback changes taste. An attempt clarifies the next action. A new possibility demands another choice. An unfamiliar problem brings someone’s earlier experience into use.They also reveal why a promising effort can stall. Perceptive judgment can remain criticism when nobody acts. Initiative can create endless beginnings when attention is scattered. Concentration can become frustration when a team cannot find another route. Clever solutions can remain demonstrations when nobody carries them into everyday work.The practical challenge for 2027 is to bring a wide world into a clear commitment.That requires something from leaders as well as individuals. Give people close to problems room to demonstrate improvements. Encourage them to encounter excellent work beyond the enterprise. Assemble small groups with complementary strengths. Help them choose an outcome and reach the people whose decisions it requires.Then stay interested during the difficult period between an impressive first version and useful adoption.There is probably a project your organization has learned to tolerate leaving unfinished. There is a team that engaged with a step of the solution, passed it along to the next team, and then moved on. Perhaps there is a report that arrives too late, a service that makes employees understand the organization before they can get help, or a process that asks suppliers to carry its complexity.Start there. This is the more valuable work that AI will enable us to accomplish.Examine what excellent work could teach you. Look at the inherited decisions being treated as permanent. Decide which other good ideas must wait. Bring the right experiences and people to the problem. Ask whether the purpose matters enough to sustain the work after the excitement fades.Then make an attempt that reveals something. Follow it into use. Let the finished contribution change your understanding of what you can attempt next.Return to the supplier at the beginning of this post. The difference becomes visible when that person can open the instructions, recognize their situation, and know what to do next. The departments can carry out their responsibilities. The purchasing process can proceed.Someone has given a piece of the enterprise enough thought and care to make it coherent.Working toward that result also gives you opportunities to grow. You encounter a distinction you could not previously see. You question an arrangement you once accepted. You learn what deserves attention, whose experience can help, and what finishing actually requires.Useful practice can also happen outside the project. Comparing interpretations of a piece of music can sharpen judgment. Learning an unfamiliar craft can teach you how to proceed when the instructions stop being sufficient. Returning to something another person has used can reveal what you overlooked when you first called it finished.Those experiences become part of what you bring to the next attempt. Their connections may become clear only when you look back.So choose a contribution worth making, and give your development a deliberate place in the year. Small exercises, encounters with different kinds of excellence, and repeated attention to the same piece of work can strengthen the capacity to finish it well.What will you make in 2027? And how will you use the year to become more capable of making it?How Will You Get Better: A Year of PracticeOne way to strengthen these skills is to spend time in situations where your usual expertise provides little help.Taste can grow through comparing performances of the same piece of music. Agency can grow through examining a household routine. Resourcefulness can grow while making something with your hands and discovering that the original plan does not work.These activities bring different experiences into your judgment. Their usefulness may become clear much later.Set aside a few focused hours each month. Keep a short record of what you tried, what surprised you, and which decision changed. Several months below return to the same contribution, giving the year a continuous thread of making, observing, and improving.January: Taste Through ComparisonChoose one work and examine three interpretations: performances of the same music, translations of a poem, or productions of a scene. Include an interpretation from a tradition unfamiliar to you.Describe the choices that make each version effective. Pay attention to pacing, emphasis, restraint, and what has been left out. Finish with a short note about one principle worth carrying into your own work.February: Agency Through an Inherited RuleChoose a recurring meeting, household routine, or shared process that persists because it is familiar. Find out who established it and what problem it originally solved.With the people involved, test one small change for two weeks. Record what improved and what remained necessary. The exercise makes a human decision visible inside something that previously felt fixed.March: Resourcefulness Through Unfamiliar CraftMake or repair something modest using materials already available. Bind a small notebook, mend a garment, or try a craft you have never practiced.Choose something that requires learning as you go. When the plan breaks down, investigate the next step and adapt. Record one moment when a constraint led to a better approach. That experience may become useful in an entirely different setting.April: Focus Through SubtractionChoose one existing commitment that deserves sustained attention. Then identify three worthwhile optional activities competing with it.Pause or defer those activities. Write down why each is attractive and why the chosen commitment matters more right now. Protect a regular period of uninterrupted attention.This exercises the difficult part of focus: declining something good.May: Follow-Through for One PersonChoose one person with a small recurring problem. Make something useful for them: clearer instructions for a volunteer, a checklist for a colleague, or a simple guide for a community group.Watch the person use it. Resolve the confusion that appears and put the revised version back into their hands. Finish the month with something another person has successfully used.June: Taste Through Someone Else’s EyesAsk someone whose craft you know little about to explain how they judge quality. A musician, gardener, editor, cook, mechanic, or illustrator could provide a different way of seeing.Ask them to compare two examples and explain the details they notice. Capture their criteria, then revisit January’s exercise. Look for distinctions you can now recognize that you previously missed.July: Agency Through a Small RedesignChoose part of your immediate environment that you can change: a workspace, a form you own, or the sequence of a routine.Before changing it, describe what the current arrangement asks people to do. Build an alternative and try it for a week. Observe whether it makes the intended action easier.Agency grows through experiencing a connection between a deliberate change and someone’s ability to act.August: Resourcefulness Through a Small TeamReturn to May’s contribution. Invite two capable people with different strengths to help improve it.One might understand the recipient’s needs deeply. Another might bring strong writing, design, or technical craft. Give them room to reshape the work and challenge your assumptions.Record which decisions became better because of their contributions. Practice assembling a small team whose combined judgment exceeds what you could bring alone.September: Focus Through EditingWrite the purpose of that contribution in one sentence. Examine every feature, paragraph, and step against it.Remove something you like that does not adequately serve the purpose. Try the simpler version with its intended user and observe what happens. Keep the change when it improves clarity or usefulness.This develops focus at the level of the finished work. Selection becomes visible in what remains.October: Follow-Through by ReturningGo back to the person using the contribution. Ask what they still work around, explain to others, or complete outside it.Observe the work in its actual setting. Choose one unresolved friction and carry the improvement through to use.Returning after several months exercises a different kind of commitment. The work has become ordinary, and the recipient’s experience still deserves attention.November: Resourcefulness Through HindsightRead the notes collected during the year. Look for earlier experiences that unexpectedly influenced later decisions.Perhaps March’s failed attempt helped you approach an unfamiliar problem. Perhaps June’s conversation changed an editing decision in September. Trace the connections through what actually happened.AI can help organize the notes and suggest patterns to examine. Judge those patterns against your record. The exercise is to recognize connections that emerged through living and making.December: Put the Five Skills TogetherChoose one existing, unfinished commitment small enough to complete this month.Bring your stronger standards to it. Examine an inherited assumption. Give it a clear purpose and enough attention. Seek the experience or collaborator needed for its difficult parts. Then finish it and put it into use.Record what the intended person can now do, understand, or experience better. Let that result inform what you choose to attempt in 2028.The useful record of this year will include encounters, changed decisions, declined possibilities, unexpected connections, and finished contributions.By December, you should have something more concrete than a claim that your skills improved: a piece of work another person can use, and a clearer understanding of how you became capable of making it.", "content_html": "The enterprise examples in this post are hypothetical.
Imagine being ready to sell something to a large company and discovering that the hardest part is figuring out how to begin.
Procurement sends one set of instructions. Legal sends another. Cybersecurity has a questionnaire. Accounts payable needs information that appears to overlap with something already submitted. Each document makes sense to the department that wrote it.
The supplier still cannot tell what happens next.
Inside this hypothetical Fortune 500 enterprise, everyone has done their part. Outside it, someone has to reconstruct the organization before they can do business with it.
That process has authors. Someone chose the questions, the sequence, the systems, and the handoffs. Those decisions were made under particular conditions, with particular tools and assumptions. Over time, they became familiar enough to feel permanent.
But they can be examined. They can be understood. They can be changed.
That realization is where making begins.
A spectator can recognize the problem, discuss it, attend a demonstration, and leave with an informed opinion. A maker accepts responsibility for carrying an improvement into the world.
These are ways of participating. The same person moves between them. Watching is useful. Reading, listening, and studying other people’s work are essential. The worker becomes the spectator when observation repeatedly replaces the difficult work of choosing, attempting, refining, and finishing.
As enterprises prepare for 2027, AI gives people more ways to explore an idea and make a first attempt. A process analyst can demonstrate an alternative. An operations team can examine a reporting problem. A small group can carry work that previously depended on several separate teams.
That creates a practical question: what will people do with the additional capacity?
A company can become very good at generating possibilities. It can fill its calendar with demonstrations and its planning system with promising initiatives. The work becomes consequential when someone chooses a particular result and stays with it long enough for another person to benefit.
Five skills help make that movement possible: taste, agency, focus, resourcefulness, and follow-through. Each shapes how a person sees the world. Each also shapes what that person leaves in it.
Taste develops through exposure to the best of humanity, across cultures, disciplines, and experiences. You encounter excellent work, give it close attention, and let it change your standards. Don’t let these best practices be merely admired. Don’t let people say that won’t work where you work. All too often you hear people say, “In theory … but in practice … So we don’t do that.” These are the voices of the spectator, the critic, and the cautious.
The attitude you need requires you to see a world larger than your immediate professional surroundings, it requires a sense of humility and a willingness to be wrong and to admit you can and should learn from others. This is the first step in developing strong taste.
So, go study a well-designed building. Read carefully edited prose. Listen to music closely enough to notice its pacing and restraint. Examine a useful tool, a thoughtful service, or a piece of craftsmanship. Look at work from another place or another period. Stay with something unfamiliar long enough to understand what makes it good.
What decisions are hidden inside it? How does it guide attention? What has been removed? What does it make easier for the person encountering it?
Those questions turn admiration into material you can use.
A person early in a career can develop strong taste in a particular area through curiosity, attention, and experimentation. Years of experience become valuable when they are examined and absorbed. Simply accumulating them does not guarantee a better judgment.
Now return to our struggling supplier.
The onboarding team could begin by rearranging the existing documents. It could also look outside the company for better ways to help a person navigate unfamiliar information.
A clear museum exhibit has to introduce a complex scientific subject without demanding that every visitor arrive as an expert. Public wayfinding has to help someone choose a route while standing in an unfamiliar place they have never been to. A library has to make a large collection discoverable to someone who doesn’t quite know what they need. Thoughtful hospitality anticipates the uncertainty of someone entering a setting they do not yet understand.
These encounters suggest useful questions for the enterprise. Can a supplier recognize their situation? Can they see the sequence? Is the next action obvious? Does specialized language appear with enough explanation to be useful?
The team builds an onboarding experience around those questions. Procurement, legal, cybersecurity, and finance still have responsibilities. The supplier receives a coherent path through them.
Then someone tries it.
A new supplier understands the explanations but cannot tell which requirements apply to a service provider working at a company location. A site purchasing coordinator notices that the proposed sequence does not match how purchasing actually proceeds.
The team revises the experience.
Exposure to excellent work in other domains provides standard of what good work looks like. Contact with actual people reveals where those standards need to be applied. Taste becomes more precise through both.
For leaders, this means giving informed judgment room to become work. Someone close to a frustrating process may see distinctions that a planning meeting misses. Let that person demonstrate an alternative. Encourage references from outside the enterprise. Examine the care and clarity of the resulting experience.
An internal service deserves this attention. It shapes how people spend their working lives.
The onboarding team uses AI to explore different information structures, draft explanations, and identify inconsistencies. It can compare several ways of presenting the same process and examine what each emphasizes.
The team might ask for a version organized around departments, another around supplier situations, and another around the sequence of decisions. Comparing them makes assumptions visible.
Members judge those alternatives against their understanding of excellent work and the needs of suppliers. They continue examining work beyond their professional field and observing people using the process.
AI supplies more material to consider. The people making the experience remain responsible for its judgment, coherence, and care.
![\"A](\"/img/2026-10/02-agency.webp\")
Agency begins with a simple realization: much of the environment around you was built by people no smarter than you.
You can learn how it works. You can influence its shape. You can build things other people use.
An enterprise’s scale can make this difficult to remember. A workflow arrives with a system name, an owner, a history, and several dependencies. It feels established. But inside it are choices about what should happen, who should act, and what information should be available.
Understanding those choices and empathising with the people who wrote it, makes useful change possible.
Consider another part of the same hypothetical company. Field supervisors receive a maintenance status report every Friday. Someone assembles it manually from information that becomes available throughout the week. The supervisors then send it to leadership by the end of the day.
An operations analyst asks why do I need to do this on Friday? The answer leads back to an older process for collecting updates in order to allow leadership to review the information on Monday morning before making decisions at a standing meeting that is now on a Wednesday. The schedule for the report survived even though the consumers of the reports no longer followed the same timeline.
The analyst works with supervisors and the system owner to demonstrate a shared view that reflects the available information more promptly. An inherited reporting schedule becomes a design question.
The first version ranks maintenance work orders by age.
The supervisors explain that age alone does not identify the work needing attention. Their concern is work scheduled for the coming week that lacks a necessary part, an available crew, or a confirmed access window.
The first attempt is imperfect. It is also useful. It gives people something concrete to examine and helps them articulate knowledge they had struggled to explain in an abstract requirements discussion.
The analyst revises the view around readiness for scheduled work.
Building has clarified the plan.
This is an important consequence of agency. You do not have to understand every step before taking the first useful one. Some understanding becomes available through the attempt itself.
A team can spend a long time agreeing that its reporting is inadequate. It can gather resources, discuss possibilities, and wait for a operational improvement program to be launched. Agency appears when someone maps the process, examines the available information, and makes an alternative that can be tested.
The result may also change the maker’s ambition. A reporting improvement could reveal a problem in the handoff between planning and field teams. The next attempt begins with a better understanding of the people, systems, and decisions involved.
The environment becomes more understandable as it becomes open to informed influence.
Over time this approach can lead to a culture where informed influence is expected and valued, making the organization more adaptive and responsive to change.
The analyst uses AI to turn process notes and system documentation into a draft explanation of how reporting works. That explanation helps identify assumptions to examine with supervisors and the system owner.
AI can help develop alternative report structures and a first version people can react to. As supervisors clarify what matters, the analyst uses it to revise the proposal and organize unanswered questions.
An unfamiliar technical step becomes something to investigate. The analyst can ask for an explanation, examine it against the underlying information, and bring a better question to the person with the relevant expertise.
The maker chooses the change to pursue, tests the understanding with the people involved, and takes responsibility for moving the work forward.
![\"One](\"/img/2026-10/03-focus.webp\")
Focus means saying no to a hundred good ideas and clearing your mind and commitments so you can say yes to the one thing that matters most.
The difficulty is that those other ideas may be worthwhile.
A diverse world supplies possibilities. Taste makes more of them visible. Resourcefulness gives you additional ways to pursue them. Eventually, you have to decide which possibility deserves the work that comes after its exciting beginning.
Return to procurement. The leadership team has several credible proposals: AI-assisted contract summaries, supplier performance dashboards, better purchasing search, improved supplier onboarding, and automated responses to routine questions.
Each has a plausible benefit. Each has an interested sponsor. Each could consume the attention of capable people.
The team chooses to improve the path from a supplier’s initial application to readiness for a first purchase and payment. It defers the other ideas and gives that outcome a clear owner, a small team, and sustained attention and.
Now decisions have something coherent to serve.
Does a proposed feature help a supplier complete that path? Does it help an employee resolve the next step? Does it remove confusion or create another place where the process can fragment?
Focus requires working through those questions until the answer is clear enough to guide action.
It also requires creating room to think. Conflicting commitments occupy the mind long after a meeting ends. An initiative that has supposedly been deferred can remain an obligation if nobody clearly tells its sponsor what was decided. A team can have one official priority and several unofficial ones.
Clarity in the result begins with clarity in the commitments behind it.
Imagine two teams with similar tools. One spends a month producing demonstrations across several procurement topics. Each demonstration attracts interest, and each new request creates another beginning.
The other stays with supplier onboarding. It works through departmental handoffs, brings suppliers through the revised process, and learns what still prevents completion.
Both teams are producing artifacts. The second team’s attention accumulates into a deeper understanding of one problem and a result that reaches people.
Curiosity still matters. Wide interests help makers discover worthwhile problems and useful approaches. The discipline is to keep curiosity broad while being selective about commitments.
A prototype should answer a question, improve a decision, or advance the chosen work. When it repeatedly creates another possibility, ask whether it is helping the commitment develop.
Leaders have work to do here. Make deferred ideas visible. Resolve competing requests. Support the team after the novelty fades. Review progress through the intended outcome and the decisions still required to achieve it.
A meaningful yes includes protecting the work from other attractive demands.
Leadership gives AI the proposed initiatives, current commitments, and criteria that matter to the enterprise. AI helps organize proposals around intended outcomes, identify overlapping work, and summarize competing demands.
That comparison gives the team material for examining tradeoffs. It can also reveal questions that need investigation before a decision is made.
Once supplier onboarding is chosen, AI helps refine a clear scope statement and identify activities that do not advance it. When new requests appear, the team can compare them with the agreed outcome and decide whether to include or defer them.
AI helps make the choices understandable. Leadership makes those choices, communicates what will be left for later, and protects the attention required to finish.
![\"Black](\"/img/2026-10/04-resourcefulness.webp\")
Resourcefulness combines diverse experience, unconventional approaches, and the strengths of small, elite teams to find a way forward.
You cannot know in advance how every experience will matter. The connections become clear as you look back.
This gives curiosity a role beyond an immediate business case. An encounter with a craft, a culture, or an unfamiliar discipline may have little obvious relevance when it happens. Years later, a problem gives it a use.
The supplier onboarding team brings together five people: a procurement specialist, a service designer, an integration engineer, an accounts payable analyst, and a site purchasing coordinator. It draws on legal, cybersecurity, and other process owners when their expertise or decisions are needed.
Each person understands something the others need.
The designer previously studied museum exhibits knows how difficult it can be to introduce unfamiliar information. The site coordinator once managed event logistics and recognizes how an unclear handoff can disrupt an otherwise thoughtful sequence. The engineer has worked on incident response and knows how unresolved ownership can hide inside a queue.
Those experiences were not acquired as preparation for supplier onboarding. Their relevance emerges through the work.
The group also shares demanding standards. Members can challenge assumptions, revise their own thinking, and contribute strong craft. “Elite” describes the quality of their judgment, learning, and commitment.
A small team becomes capable through the combination of its members and access to the people whose participation the problem requires.
At first, this team assumes that the onboarding experience will require a substantial new platform. As it examines the process, it finds useful capabilities already present in existing systems. It also finds redundant requests, confusing explanations, and handoffs that can be redesigned.
The solution becomes a combination of clearer information, revised responsibilities, and better use of existing capabilities.
The outcome the team is working on stays the same. The path they take to reach it changes.
Resourcefulness depends on being able to make that adjustment. The maker cares enough about the purpose to reconsider how it should be achieved.
Learning continues near the point of need. The procurement specialist learns enough about information design to evaluate the experience. The engineer learns why particular payment requirements matter. The designer learns how purchasing differs between business units.
Each explanation has a concrete use. It serves a problem the team cares about.
Finishing the work adds another set of experiences. Looking back, members can see which earlier ideas mattered, where a colleague’s perspective changed the result, and what they are better prepared to attempt next. This reflection can only be done after the product is shippped. It is an essential part of developing the team.
For leaders, the useful question is how people behave when they reach unfamiliar territory. Do they find a useful question? Reframe the problem? Seek help? Return with another informed attempt?
Give small teams access to the expertise and decisions their work requires. Let them question the expected route while keeping the purpose clear.
The team uses AI to explain specialist terms and compare how departments describe the same process. This can make it easier for members to understand one another’s concerns.
They can explore possible connections between information design, logistics, incident response, and supplier onboarding. AI helps generate candidate approaches using the capabilities and constraints the team has identified.
When an unfamiliar technical or procedural problem appears, AI helps explain it and prepare useful questions for the relevant expert.
It can also support reflection. After a delivery milestone, the team uses AI to organize decisions and feedback, then examines how earlier experiences contributed to the result.
The people supply lived experience, judge the proposed connections, and choose the route that serves the purpose.
![\"One](\"/img/2026-10/05-follow-through.webp\")
Great ideas are cheap. Follow-through is the passion and discipline to do the grueling work that turns an idea into something excellent, finished, and usable.
An idea can be compelling before any of its difficult details have been resolved. A demonstration can make the result look close.
Then the details arrive.
Information does not reach the right system. A person does not know who owns an exception. A sequence works for one business unit and becomes confusing in another. An explanation has to be rewritten. Someone has to prepare the people who will operate the service.
Given all these challenges, it will be tempting to move the goal posts and to cut corners. With each adjustment, the team risks undermining the very experience it is trying to create. Discipline and commitment are required to maintain the integrity of the work through these difficulties.
Passion matters at this point because it gives the work a reason to continue through this period. Care has to survive the loss of novelty and the temptation to settle for something short of a bullseye.
The supplier onboarding team demonstrates a clear, attractive experience. During the pilot, suppliers complete the intake successfully. But some information does not reach the purchasing system correctly. Site buyers remain uncertain about who handles exceptions. Accounts payable discovers that a completed intake does not always provide everything needed to prepare for the first payment.
The team stays involved. Just because the project is “over” in the sense of the initial rollout does not mean the work is complete.
It corrects the information handoffs, clarifies responsibility, revises instructions around the purchasing sequence, prepares employees to use the process, and establishes continuing ownership.
These tasks determine whether the experience holds together. They are part of making the idea real.
This is what Steve Jobs meant when he said: “Real artists ship.”
Shipping requires bringing work to a condition where its intended recipients can use or experience it. It requires decisions about what belongs, resolution of important problems, and completion of the path into use.
There are layers to that completion. The work has to exist. Its details have to meet the intended standard. It has to reach people in their actual circumstances. It has to fulfill its purpose. Someone has to carry responsibility for its future. The user has to be able to engage with it successfully to achieve their intended outcome.
A maker follows the work through those layers. A spectator does their small bit, and throws the work over the fence.
For the supplier, success means understanding what is needed and being able to complete the process. For the site buyer, it means knowing the status, the next action, and who can resolve a problem. For procurement and finance, it means receiving the information necessary to carry out their responsibilities.
The whole job exists across those relationships.
This also changes how colleagues come to trust someone. They learn whether that person remains involved after a promising beginning. Process owners see whether difficult details receive care. Recipients experience whether the work delivers what was promised.
A reputation develops through the quality and reliability of completed contributions.
The team uses AI to organize pilot feedback into problems involving explanations, information handoffs, responsibilities, and exceptions. It helps prepare test scenarios that follow different suppliers through the complete process.
AI can assist with revised instructions, employee training materials, and guidance for the people who will operate the service. The team compares those materials with the implemented process and looks for gaps or inconsistencies.
After release, AI helps summarize recurring questions and reported problems. That gives the team another way to identify what deserves attention.
The maker validates the work, coordinates its release, observes its use, and remains responsible for the promised result. AI helps carry the tasks. Passion and commitment keep the people engaged with the purpose.
These skills operate together. Feedback changes taste. An attempt clarifies the next action. A new possibility demands another choice. An unfamiliar problem brings someone’s earlier experience into use.
They also reveal why a promising effort can stall. Perceptive judgment can remain criticism when nobody acts. Initiative can create endless beginnings when attention is scattered. Concentration can become frustration when a team cannot find another route. Clever solutions can remain demonstrations when nobody carries them into everyday work.
The practical challenge for 2027 is to bring a wide world into a clear commitment.
That requires something from leaders as well as individuals. Give people close to problems room to demonstrate improvements. Encourage them to encounter excellent work beyond the enterprise. Assemble small groups with complementary strengths. Help them choose an outcome and reach the people whose decisions it requires.
Then stay interested during the difficult period between an impressive first version and useful adoption.
There is probably a project your organization has learned to tolerate leaving unfinished. There is a team that engaged with a step of the solution, passed it along to the next team, and then moved on. Perhaps there is a report that arrives too late, a service that makes employees understand the organization before they can get help, or a process that asks suppliers to carry its complexity.
Start there. This is the more valuable work that AI will enable us to accomplish.
Examine what excellent work could teach you. Look at the inherited decisions being treated as permanent. Decide which other good ideas must wait. Bring the right experiences and people to the problem. Ask whether the purpose matters enough to sustain the work after the excitement fades.
Then make an attempt that reveals something. Follow it into use. Let the finished contribution change your understanding of what you can attempt next.
Return to the supplier at the beginning of this post. The difference becomes visible when that person can open the instructions, recognize their situation, and know what to do next. The departments can carry out their responsibilities. The purchasing process can proceed.
Someone has given a piece of the enterprise enough thought and care to make it coherent.
Working toward that result also gives you opportunities to grow. You encounter a distinction you could not previously see. You question an arrangement you once accepted. You learn what deserves attention, whose experience can help, and what finishing actually requires.
Useful practice can also happen outside the project. Comparing interpretations of a piece of music can sharpen judgment. Learning an unfamiliar craft can teach you how to proceed when the instructions stop being sufficient. Returning to something another person has used can reveal what you overlooked when you first called it finished.
Those experiences become part of what you bring to the next attempt. Their connections may become clear only when you look back.
So choose a contribution worth making, and give your development a deliberate place in the year. Small exercises, encounters with different kinds of excellence, and repeated attention to the same piece of work can strengthen the capacity to finish it well.
What will you make in 2027? And how will you use the year to become more capable of making it?
One way to strengthen these skills is to spend time in situations where your usual expertise provides little help.
Taste can grow through comparing performances of the same piece of music. Agency can grow through examining a household routine. Resourcefulness can grow while making something with your hands and discovering that the original plan does not work.
These activities bring different experiences into your judgment. Their usefulness may become clear much later.
Set aside a few focused hours each month. Keep a short record of what you tried, what surprised you, and which decision changed. Several months below return to the same contribution, giving the year a continuous thread of making, observing, and improving.
Choose one work and examine three interpretations: performances of the same music, translations of a poem, or productions of a scene. Include an interpretation from a tradition unfamiliar to you.
Describe the choices that make each version effective. Pay attention to pacing, emphasis, restraint, and what has been left out. Finish with a short note about one principle worth carrying into your own work.
Choose a recurring meeting, household routine, or shared process that persists because it is familiar. Find out who established it and what problem it originally solved.
With the people involved, test one small change for two weeks. Record what improved and what remained necessary. The exercise makes a human decision visible inside something that previously felt fixed.
Make or repair something modest using materials already available. Bind a small notebook, mend a garment, or try a craft you have never practiced.
Choose something that requires learning as you go. When the plan breaks down, investigate the next step and adapt. Record one moment when a constraint led to a better approach. That experience may become useful in an entirely different setting.
Choose one existing commitment that deserves sustained attention. Then identify three worthwhile optional activities competing with it.
Pause or defer those activities. Write down why each is attractive and why the chosen commitment matters more right now. Protect a regular period of uninterrupted attention.
This exercises the difficult part of focus: declining something good.
Choose one person with a small recurring problem. Make something useful for them: clearer instructions for a volunteer, a checklist for a colleague, or a simple guide for a community group.
Watch the person use it. Resolve the confusion that appears and put the revised version back into their hands. Finish the month with something another person has successfully used.
Ask someone whose craft you know little about to explain how they judge quality. A musician, gardener, editor, cook, mechanic, or illustrator could provide a different way of seeing.
Ask them to compare two examples and explain the details they notice. Capture their criteria, then revisit January’s exercise. Look for distinctions you can now recognize that you previously missed.
Choose part of your immediate environment that you can change: a workspace, a form you own, or the sequence of a routine.
Before changing it, describe what the current arrangement asks people to do. Build an alternative and try it for a week. Observe whether it makes the intended action easier.
Agency grows through experiencing a connection between a deliberate change and someone’s ability to act.
Return to May’s contribution. Invite two capable people with different strengths to help improve it.
One might understand the recipient’s needs deeply. Another might bring strong writing, design, or technical craft. Give them room to reshape the work and challenge your assumptions.
Record which decisions became better because of their contributions. Practice assembling a small team whose combined judgment exceeds what you could bring alone.
Write the purpose of that contribution in one sentence. Examine every feature, paragraph, and step against it.
Remove something you like that does not adequately serve the purpose. Try the simpler version with its intended user and observe what happens. Keep the change when it improves clarity or usefulness.
This develops focus at the level of the finished work. Selection becomes visible in what remains.
Go back to the person using the contribution. Ask what they still work around, explain to others, or complete outside it.
Observe the work in its actual setting. Choose one unresolved friction and carry the improvement through to use.
Returning after several months exercises a different kind of commitment. The work has become ordinary, and the recipient’s experience still deserves attention.
Read the notes collected during the year. Look for earlier experiences that unexpectedly influenced later decisions.
Perhaps March’s failed attempt helped you approach an unfamiliar problem. Perhaps June’s conversation changed an editing decision in September. Trace the connections through what actually happened.
AI can help organize the notes and suggest patterns to examine. Judge those patterns against your record. The exercise is to recognize connections that emerged through living and making.
Choose one existing, unfinished commitment small enough to complete this month.
Bring your stronger standards to it. Examine an inherited assumption. Give it a clear purpose and enough attention. Seek the experience or collaborator needed for its difficult parts. Then finish it and put it into use.
Record what the intended person can now do, understand, or experience better. Let that result inform what you choose to attempt in 2028.
The useful record of this year will include encounters, changed decisions, declined possibilities, unexpected connections, and finished contributions.
By December, you should have something more concrete than a claim that your skills improved: a piece of work another person can use, and a clearer understanding of how you became capable of making it.
", "url": "https://tedt.org/Makers-vs-Spectators/", "image": "/img/2026-10/00-makers-vs-spectators.webp", "tags": ["enterprise AI","makers","taste","agency","focus","resourcefulness","follow-through","professional development"], "date_published": "2026-10-11T00:00:00-07:00", "date_modified": "2026-10-11T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/The-Future-of-Corporate-Work/", "title": "The Future of Corporate Work", "summary": "AI makes some forms of execution more abundant, increasing the importance of the systems that turn execution into accepted outcomes.", "content_text": "Imagine a company that can prepare an analysis in minutes. Its systems gather records, compare alternatives, draft recommendations, and assemble a presentation. The proposal still waits for someone to settle conflicting priorities, authorize spending, and accept responsibility for the decision.The company has accelerated most of the work processes, but not the overall workflow. Whether it has become a better company depends on what happens next.That is the central question of corporate work in the age of AI. The Information Age, which began to appear in the mid-20th century, made it easier to store, find, copy, and move information. AI extends the automation of interpreting that information and using it to perform tasks. When a useful procedure can be reproduced across many AI agents, an organization gains a different way to expand its capacity.The consequences reach beyond individual productivity. They affect why companies have departments, how people learn, where authority belongs, what a finished job costs, and who benefits from the work.My argument is that AI makes some forms of execution more abundant, increasing the importance of the systems that turn execution into accepted outcomes. The future corporation will need to combine reusable knowledge, bounded machine action, human judgment, and accountable decisions. Its success will depend on the design of that combination.What the Information Age EstablishedThere is no single, agreed doctrine of the Information Age. Alvin and Heidi Toffler, Daniel Bell, Peter Drucker, Manuel Castells, and later writers described overlapping changes while disagreeing about their causes, desirability, and likely outcomes. The following summary groups the corporate implications of the broader Information Age transformation. These are named themes, rather than eighteen universally accepted laws. The writers listed are foundational contributors or particularly useful specialists for each subject; this is a reading map, not a ranking by publication volume. Information Age idea What it describes Leading contributors and major work 1. Knowledge as a productive resource Expertise and theoretical knowledge become central to production, alongside physical assets and labor. Organizations must convert knowledge into performance. Daniel Bell, The Coming of Post-Industrial Society (1973); Peter Drucker, Post-Capitalist Society (1993) and his knowledge worker productivity research; Alvin and Heidi Toffler, Revolutionary Wealth (2006). 2. Reusable knowledge and collective memory Knowledge can be shared and reused without being consumed in the way a physical input is. Networks make distributed contributions useful to others. The Tofflers on knowledge and wealth; Yochai Benkler, The Wealth of Networks (2006). 3. Attention scarcity and information overload More available information increases demands on the people receiving it. Filtering and allocating attention become organizational tasks. Herbert A. Simon, “Designing Organizations for an Information-Rich World” (1971). 4. Acceleration and institutional mismatch Technology, social practices, and institutions change at different speeds. Faster tools can increase pressure rather than create free time. Alvin Toffler, Future Shock (1970); Hartmut Rosa, Social Acceleration (English edition 2013); Carlota Perez, Technological Revolutions and Financial Capital (2002). 5. Network enterprises and adaptive organization Firms coordinate expertise, suppliers, and projects through networks. Flexible activity can coexist with concentrated decision-making. Manuel Castells, The Information Age trilogy (1996–1998); Thomas W. Malone, The Future of Work (2004). 6. Decentralized decisions and specialist autonomy Knowledge work raises questions about who has the expertise to decide. In traditional organizations leaders decide. In information based organizations, experts decide, regardless of their elevation in the company. Technology expands the ways groups can coordinate decisions. Drucker on knowledge worker productivity; Malone, Superminds (2018), on hierarchies, markets, democracies, and communities. 7. Customization and the experience economy Organizations serve varied needs through tailored products, services, and experiences. Customization can coexist with large production volumes. B. Joseph Pine II and James H. Gilmore, Mass Customization and The Experience Economy (1999); Alvin Toffler, The Third Wave (1980). 8. Flexible time and place of work Telecommunications loosen the relationship between some work and a shared office. Some tasks need presence and contact while others do not. Alvin Toffler, the “electronic cottage” in The Third Wave; Castells on networked time and space. 9. Repeated learning and changing careers Expertise needs renewal as work changes. Learning extends beyond a single period of formal education and beyond classrooms. Drucker on knowledge work; Ivan Illich, Deschooling Society (1971), especially learning webs; Toffler on adaptation. 10. Prosumers and peer production of products Customers and users help produce, improve, or create the products they use. Productive collaboration can occur outside conventional employment. Toffler on the prosumer; Benkler on peer production; Eric von Hippel, Democratizing Innovation (2005). 11. Unpaid work and incomplete measures of value Market transactions and company accounts leave out important contributions to overall value. A business can also reduce its own costs by transferring work to its customers. Toffler on the unpaid economy; Mariana Mazzucato, The Value of Everything (2018); Daron Acemoglu and Simon Johnson on work transfer and automation. 12. Data power and platform concentration Distributed participation demands a more centeralized concentration of data and platforms controlled by a few, but more empowered gatekeepers. Shoshana Zuboff, The Age of Surveillance Capitalism (2019); Nick Srnicek, Platform Capitalism. 13. Technological choice and the distribution of gains Higher productive capacity does not automatically produce broadly shared prosperity. Technology can complement people, replace tasks, or strengthen control over work. Acemoglu and Johnson, Power and Progress (2023); Mazzucato on value creation and extraction. 14. Identity and belonging under change Flexible institutions and digital environments alter relationships, identity, and security. Adaptability has human consequences. Zygmunt Bauman, Liquid Modernity (2000); Luciano Floridi, The Fourth Revolution (2014). 15. Interdependence and system fragility Connected systems contain feedback, delays, and dependencies. Improving one component can produce unexpected effects elsewhere. Donella H. Meadows, Thinking in Systems (2008) and “Leverage Points”; the Tofflers on synchronization. 16. Physical infrastructure and resource constraints Communication depends on material systems. Energy, logistics, equipment, and environmental limits remain part of everyone’s economic value chain. Jeremy Rifkin, The Third Industrial Revolution (2011) and The Zero Marginal Cost Society (2014); Meadows on systems and limits. 17. Anticipatory governance and multiple futures Institutions need ways to prepare for uncertainty and adjust their rules of governance and risk. Scenarios help examine assumptions before events settle them. Peter Schwartz, The Art of the Long View (1991); Perez on technological and institutional transitions; Toffler on anticipation. 18. Truth and the purposes of technology Information systems shape what people recognize as knowledge, authority, and progress. Their usefulness requires standards beyond technical capability that reaches into epsitomology. Neil Postman, Technopoly; Floridi on life within an information environment; Toffler on competing tests of truth. This foundation sets us up for the next transformation. However everything above in is tenstion. Networks can disperse activity while concentrating control. Customization can expand choice while intensifying measurement. Faster communication can increase the burden of coordination. A company can appear more productive because someone outside its accounts is doing more unpaid work.The above helps us see the possibilities. Do not assume that every technical improvement produces an organizational or social improvement.Twelve Principles for AI in an Information Age EconomyThe starting list needs both extension and refinement. The principles below combine empirical findings, practical engineering lessons, and proposed rules for corporate design. Where a conclusion is a proposal or a forecast, I treat it as such.1. AI Fluency Is a Learned Skill With Durable FoundationsUsing AI well involves choosing an appropriate task, explaining the outcome, supplying relevant context, checking the result, and knowing when to stop or escalate. Familiarity with one interface is only part of that skill.In Crucial Prompting, I described prompting as a communication practice. The Skill that Outgrows the Tool pushes the argument further: translating business problems into useful systems is more durable than memorizing a product’s controls.The evidence also suggests that expertise and AI assistance interact. In Generative AI at Work, Erik Brynjolfsson, Danielle Li, and Lindsey Raymond found different effects across customer support workers, including larger gains for less experienced workers and evidence of learning. That study concerns a particular work setting; it does not establish a universal learning curve for every AI user.The implication is a training proposal: teach problem definition, judgment, verification with validation, and workflow design together.2. The Economic Unit Is a Verified and Accepted OutcomeA response, a tool call, and a completed business action are outputs needed at different times, and in the past might be considered atomic products. Today, we recognize them as parts of a workflow that culminates in an accepted outcome. That accepted outcome needs a defined acceptance standard.The Cost of a Finished Job makes the practical case for measuring the whole workflow. Sayash Kapoor and colleagues make a related research argument: agent evaluations need to consider cost alongside accuracy.I propose:Cost per accepted outcome = total attributable workflow cost ÷ outcomes that meet the agreed acceptance standard.The numerator includes model and compute usage, data and tools, allocated design and integration work, human review, retries, rework, operational support, and expected residual failure costs. Failed attempts remain in the numerator. Avoid counting the same rework twice.Quality, timeliness, purpose, and acceptable risk must be specified separately. A cheap outcome that causes unacceptable harm is a failed choice, even if its invoice is small.3. AI Execution Scales Through Replication Within ConstraintsAn organization of people can scale by adding more individuals, but each person brings unique experience, relationships, and judgment that cannot be perfectly replicated. This generally takes months of time to onboard, develop, and integrate new team members effectively.An organization that uses AIcan run additional instances of an agent and a configured workflow. It cannot reproduce an experienced person’s full history, relationships, and judgment by copying a file. However, if the organization has well designed processes, workflows, data definitions, accountaiblities, and defined avenues of autonomy, it can leverage replication to achieve scale.This makes replication a consequential economic difference. It does not make copies free, independent, or automatically better. Each instance needs resources and a well thought out design. The danger is that a flawed design can propagate widely and it can affect all replicated instances.Google’s research on agent scaling shows why task structure matters: parallel work can benefit from multiple agents, while sequential dependencies and coordination costs can undermine the gains. The useful proposition is conditional: replicate work where its additional accepted outcomes justify the additional resources. The ability to identify parallelizable tasks is a hard problem that is studied in both organizational theory and computer science.4. Humans and Agents Both Need CoordinationHumans scale through hierarchy, teaching, specialization, and collaboration. Malone’s Superminds and Benkler’s peer production research describe others.Agent systems scale through replication and task allocation, boundary definitions, shared states, and rules for combining results. Anthropic’s multi-agent research system, for example, uses an orchestrator and workers with defined assignments.The relevant difference is how capacity can be reproduced and coordinated. A swarm still has an organizational design. The corporate question is which decisions belong to a person, a team, a rule, or a AI Agent for a particular kind of work. Some tasks are better suited for human judgment, while others can be efficiently handled by agents.5. Capability Has Uneven BoundariesA system can perform one task well and fail on a nearby task that appears similar.Fabrizio Dell’Acqua, Ethan Mollick, and their coauthors call this the jagged technological frontier. Their experiment with consultants found improvements on tasks within the tested model’s capabilities and worse performance on a task outside that frontier.This argues for evaluating specific work rather than declaring that a model can replace an occupation you find in an industrial age company. Jobs contain tasks with different demands, dependencies, and consequences. Capability assessments also expire as models, tools, and work change.All of this means is that job descriptions are going to change drastically as work is card sorted between humans and AI agents.6. The Whole System Performs the JobA model contributes gneral world knowldge. An agent knows a process. It also needs context, identity, permissions, tools, records, execution logic, and recovery.The AI Value Stream examines that chain. The lesson is that an upgrade to any of those components, even a model upgrade, can leave the actual service unchanged when another component limits performance.An impressive demonstration becomes an operating capability only after the surrounding system can deliver its promised outcome. You must evaluate the assembled service, including the people who operate, review and maintain it.7. Shared Memory Needs GovernanceA corrected answer in one conversation does not necessarily improve every other agent instance. Organizations must deliberately capture, validate, and distribute useful corrections.This is a design implication of reusable knowledge: collective memory should record sources, owners, effective dates, exceptions, and decisions. Teams need ways to remove obsolete information as well as add new information. If your organization does not have a process for removing old information or fixing errors, the value of the shared memory will degrade over time and is probably not AI ready now.Knowledge Management is the core capability. Its value comes from reliable reuse. A larger archive alone does not establish that reliability.8. Verification and Validation Must Be Stronger Than Repeated AgreementMultiple agents agreeing can reflect a shared source or a shared error. Fluent prose does not establish that an action was correct.When AI Moves Faster Than the Organization distinguishes system capability from the appearance of coordinated activity. My design rule is to use verification appropriate to the consequence: original records for factual claims, execution tests for software behavior, reconciliation for financial records, and qualified review where judgment is required.Another AI can assist with checking. It should be evaluated as a checker, rather than assumed to provide independent confirmation.9. Autonomy and Authority Are Separate DecisionsA system may be capable of acting with little supervision while lacking permission to make a particular commitment.Corporate design must specify what it may access, change, spend, disclose, and approve; when it must escalate; and which human or institution remains accountable. These decisions belong with the workflow.The distinctions in When AI Moves Faster Than the Organization are useful here: throughput, intelligence, autonomy, authority, and business value describe different properties. Increasing one does not prove that the others increased.10. Faster Execution Moves BottlenecksWhen preparation becomes faster, the limiting work may move to review, prioritization, approval, or delivery.When Output Becomes Abundant frames this as a shift toward judgment, alignment, and trust. I treat that as a useful forecast to test, rather than a universal description of every workplace.Corporate measurement should follow the entire outcome. If faster drafting merely fills a reviewer’s queue, the organization has moved its waiting time. The next improvement must address that queue and the reasons decisions wait.11. Portability Includes the Working ProcessSwitching model providers is one kind of portability. Preserving quality, controls, operating evidence, and cost while moving a business process is a larger undertaking.Model Portability Is Not AI Portability argues for control over the workflow contract, evaluations, identity and authorization, records of operation, and recovery arrangements.The proposed principle is to make important capabilities replaceable at the system level. Otherwise, apparent model choice can conceal dependence on a provider’s surrounding infrastructure.12. Human Development and Shared Gains Are Design ChoicesAI can assist learning and expand participation. It can also remove tasks through which novices acquire experience, increase surveillance, or concentrate gains.Which result follows depends partly on how the organization designs work and allocates benefits. Acemoglu and Johnson’s argument for technology that complements workers supplies an economic foundation. Beyond the Mirror supplies the normative direction: shared purpose, a living commons, coordinated autonomy, and shared capability gains.I propose treating learning opportunities, employee voice, and the distribution of benefits as explicit decisions. Their value should enter the design before the organization counts its savings.How AI Changes the Information Age IdeasThe table below is my synthesis of the preceding arguments. These are proposed implications and choices, rather than predictions attributed to the earlier writers. Each row connects an Information Age theme to the AI principles.If I were to pick the top three changes that deserve particular attention.First, the scarcity changes. Access to an answer can become easier while reliable context, attention, authority, or physical delivery remain scarce.Second, the unit of organization changes. Headcount becomes a less complete account of execution capacity when a team can reproduce software workflows. The work still belongs within institutions that resolve conflicts and accept consequences.Third, the distribution question becomes more urgent. Broad access to useful tools can coexist with narrow ownership of the infrastructure and the gains. Participation, decision rights, and ownership must be examined separately. Information Age idea What AI changes Recommendations 1. Knowledge as a productive resource Some applications of expertise can be reproduced in software. Useful results still depend on context and evaluation. Invest in the system that applies knowledge, and preserve the expertise needed to judge it. 2. Reusable knowledge and collective memory Shared knowledge can guide many executing instances. A stale rule can also spread widely. Maintain sources, versions, corrections, and permissions as part of the operating capability. 3. Attention scarcity and information overload Generating more analysis becomes easier. Review and decision capacity can become limiting inputs. Measure demands on recipients and route only information that serves a decision or action. 4. Acceleration and institutional mismatch Execution can outpace policy, procurement, training, and approval. Match deployment speed to the organization’s capacity to govern and absorb the work. 5. Network enterprises and adaptive organization Teams can add temporary machine capacity around a task. Dependencies and coordination costs still shape the result. Organize execution around actual work dependencies and bounded assignments. 6. Decentralized decisions and specialist autonomy Expertise becomes more accessible, while tools can also centralize control. Allocate decision rights explicitly, with limits and accountable owners. 7. Customization and the experience economy Tailoring information and some services can become cheaper. Tailored content can also overwhelm or manipulate. Evaluate customer benefit and consent alongside the economics of personalization. 8. Flexible time and place of work Agents can continue bounded work across locations and hours. People can face expanded expectations of availability. Design handoffs, escalation windows, and protected time for human workers. 9. Repeated learning and changing careers Assistance can support learning; automation can remove practice opportunities. Retain apprenticeships, supervised responsibility, and ways to assess skill without assistance. 10. Prosumers and peer production More users may create tools, analyses, and services themselves. Infrastructure ownership can remain concentrated. Support participation and clarify ownership, support obligations, and exit options. 11. Unpaid work and incomplete measures of value Apparent savings can hide review and repair performed elsewhere. Track total workflow burdens and accepted outcomes, including work transferred to others. 12. Data power and platform concentration More activity can flow through providers that supply models, tools, and coordination. Preserve appropriate control over records, permissions, evaluations, and process portability. 13. Technological choice and the distribution of gains Greater capacity expands the choices about displacement, augmentation, and rewards. Decide how benefits support pay, development, service quality, reduced burdens, or new capabilities. 14. Identity and belonging under change Familiar tasks and signals of expertise can change quickly. Give people meaningful participation, continuity, and a role in defining successful work. 15. Interdependence and system fragility Fast actions can propagate mistakes through connected processes. Bound actions, monitor downstream effects, and build recovery and independent checks. 16. Physical infrastructure and resource constraints Replicated execution increases demand for compute and supporting infrastructure; physical delivery retains its own limits. Include capacity, resource use, and physical dependencies in service economics and planning. 17. Anticipatory governance and multiple futures Rapidly changing capability makes fixed assumptions less reliable. Use scenarios, staged deployments, review dates, and reversible commitments where possible. 18. Truth and the purposes of technology Persuasive output can be produced at scale. Its volume does not establish its validity or social value. Require evidence, contestability, and a clear account of whose purpose the work serves. Jobs Likely to Be Deemphasized and the Work That Grows in ImportanceThe strongest forecast concerns roles organized mainly around repeatable information handling. As reliable automation improves, companies may place less emphasis on manually producing standard artifacts and more on defining, verifying, and delivering the outcomes those artifacts support.The ILO and NASK’s 2025 occupational exposure study identifies clerical occupations as particularly exposed and emphasizes that most occupations contain tasks requiring human input. Exposure describes technical potential; it does not establish adoption, layoffs, or the disappearance of a profession.The following list is my conditional forecast of corporate work redesign. It assumes that a company can meet its acceptance and risk standards at a worthwhile total cost. Demand, regulation, customer preferences, and new services can change staffing in either direction. Types of jobs likely to receive less emphasis in their current form Work likely to be deemphasized Outcomes that become more important Data entry clerks and routine administrative processors Copying records, transcribing standard forms, and moving information between systems. Accurate, timely records; resolved exceptions; traceable corrections. Reporting analysts and presentation production staff Assembling recurring dashboards, summarizing familiar data, and formatting slides. A supported decision, a clear explanation of uncertainty, and follow-through on the decision. First line customer service and internal help desk staff Answering standard questions, locating policies, and routing familiar requests. Verified resolution, customer understanding, and effective handling of difficult or sensitive cases. Software developers focused on routine implementation Writing standard boilerplate, straightforward transformations, and familiar integrations. Maintainable software that meets real requirements and works safely within its larger system. Testers focused on repetitive manual checks Repeating standard test steps and preparing routine test artifacts. Evidence that important behavior works, including failure cases and interactions between systems. Research assistants and document review analysts Gathering sources, extracting fields, and preparing first summaries of familiar material. Reliable evidence, identification of conflicting findings, and an argument that survives scrutiny. Content writers producing generic marketing material Creating routine copy variations, standard product descriptions, and undifferentiated summaries. Distinctive communication that is accurate, useful to its audience, and consistent with the organization’s commitments. Bookkeeping and finance operations staff handling standard transactions Coding familiar transactions, extracting invoice fields, and preparing routine reconciliations. Correct accounts, resolved discrepancies, and evidence supporting authorized transactions. Recruiting coordinators and staff performing preliminary screening Scheduling interviews, formatting candidate records, and summarizing applications against stated criteria. A fair, documented hiring process with accountable decisions and meaningful candidate communication. Compliance staff focused on document assembly Retrieving standard policies, mapping familiar requirements, and drafting routine evidence packages. Demonstrated compliance, identified gaps, and a defensible account of how obligations were met. Project coordinators focused on status collection Chasing updates, compiling meeting notes, and maintaining routine schedules. Dependencies resolved, commitments kept, and risks addressed before they obstruct delivery. Management roles dominated by information relay Passing status upward, distributing standard instructions, and assembling reports from other reports. Priorities settled, resources allocated, people developed, and decisions owned. Training staff producing standard course material Drafting generic lessons, quizzes, and summaries. Demonstrated capability, useful feedback, and a path from beginner practice to independent responsibility. Procurement and logistics staff focused on routine planning Comparing standard offers, preparing documents, and drafting familiar schedules. Authorized purchases and reliable physical delivery, with supplier, capacity, and operational risks managed. Several of these jobs already include substantial judgment and relationship work. Their titles may remain while their task mix changes. The forecasting claim applies most strongly where routine production dominates the role.The outcomes also need clear measures. “A supported decision” means someone can identify the evidence, the alternatives, and the accountable decision-maker. “Verified resolution” means the issue is actually resolved for the person affected. “Reliable delivery” includes the physical result, rather than a completed planning document.Processes and Skills Needed for Future WorkTo produce those outcomes, companies need repeatable processes that connect intention, execution, evidence, and responsibility. The table is a proposed operating framework; it applies across the job types above. Process What it needs to accomplish Skills needed Outcome definition and acceptance Agree on the need, constraints, evidence of completion, service timing, and unacceptable risks before execution. Problem framing, domain expertise, clear writing, customer understanding, and negotiation. Workflow design and delegation Separate independent tasks from dependent decisions; allocate work to people, agents, and established software. Process analysis, systems thinking, AI fluency, task decomposition, and coordination. Context and knowledge maintenance Keep authoritative information accessible, current, permissioned, and correctable. Information architecture, data stewardship, source evaluation, and documentation. Evaluation and verification Test the service against real cases, inspect failures, and check that evidence supports the claimed outcome. Experimental design, statistical reasoning, software testing, critical thinking, and professional judgment. Authorization and accountable action Bound access and commitments, provide escalation, and keep an understandable record of decisions and actions. Governance design, risk assessment, security literacy, ethical reasoning, and decision-making. Exception handling and recovery Recognize unusual situations, involve appropriate people, restore service, and learn from failures. Diagnosis, troubleshooting, incident response, adaptability, and communication under pressure. Economics and continuous improvement Measure total cost per accepted outcome, locate bottlenecks, and check who bears the remaining burden. Financial literacy, measurement, causal reasoning, capacity planning, and supplier evaluation. Learning and collaborative development Preserve practice, coach people, resolve disagreements, and ensure that improvements expand useful human capability. Teaching, feedback, facilitation, relationship building, conflict resolution, and change leadership. These needs suggest growing responsibilities for outcome owners, enterprise architects, evaluation specialists, knowledge stewards, service reliability teams, and educators. Organizations may assign them to existing roles or create new ones. They are proposed responsibilities, rather than a promise that a particular new title will become common.The most basic way to say this is that the essential skill is the ability to connect a real need to a reliable result while working with other people. AI fluency becomes part of that capability. Technical and domain knowledge remain necessary to understand the system, recognize its limits, and challenge its output.What the Future Corporation Should BecomeThese implications suggest an operating model. They do not imply that every company needs fewer employees, fewer departments, or a swarm of agents.Organize Execution Around Outcomes and DependenciesTake a hypothetical supplier review. Researching several suppliers can happen in parallel. Resolving conflicting contract terms, approving a purchase, and committing funds depend on earlier findings and authorized decisions.The useful structure is a workflow that reflects those dependencies. Each assignment needs a defined outcome, relevant sources, constraints, an acceptance test, and an escalation path. A shared record should show what happened and what remains uncertain.A department chart helps identify responsibility. A map of the work helps determine where execution can proceed independently, where results must be combined, and where action must wait.AI increases the value of having both.Give Management a Clearer PurposeWhere a managerial layer primarily relays information, automation may change its workload. Managers also resolve competing aims, allocate resources, develop people, negotiate obligations, and accept responsibility.My forecast is that those functions become more visible when routine preparation is easier. The organization should evaluate a layer by the decisions and commitments it contributes, rather than assume that an agent can inherit its role.This is also why replacing reporting meetings with automated reports may achieve little. The unresolved issue may be a disagreement about priorities. A system can present the disagreement clearly; someone still needs legitimate authority to settle it.Build Learning Into the WorkSenior judgment has a production history. People develop it by attempting work, seeing consequences, receiving feedback, and taking progressively greater responsibility.If an organization automates all of a novice’s early work, it should examine how that person will gain experience. A proposed alternative is to use AI for coaching and comparison while preserving meaningful practice: explain an answer, challenge its evidence, perform selected tasks independently, and own bounded decisions under supervision.The relevant question is whether today’s efficient workflow also produces tomorrow’s capable colleagues.Treat Interfaces as Part of a Governed ServiceAgents Don’t Click argues that software increasingly needs to support operators that are machines. The title is a provocation: agents can use graphical interfaces, and people still need useful ones.The corporate implication I draw is to expose important actions through clear, authorized operations with reliable records. People need ways to inspect, intervene, and challenge those actions. Both forms of access belong to the same governed service.This makes business rules, permissions, and evidence of execution strategic assets. A polished screen is one way to use that service; an agent may use another.Make Shared Purpose ConcreteBeyond the Mirror describes a corporation organized around shared purpose, a living commons, coordinated autonomy, and shared gains. Those principles can become operating decisions.Shared purpose means the people affected can help define useful outcomes. A living commons means knowledge has maintainers and a correction process. Coordinated autonomy means freedom within understood responsibilities and limits. Shared gains means the company makes explicit choices about how improvements benefit the people contributing to them.An organization can put those choices into budgets, roles, learning opportunities, and measures of service quality. Faster execution makes their absence harder to excuse.The Corporate Question After AIReturn to the imagined company whose analysis arrives in minutes.Its next step is to determine what the analysis supports, whose needs matter, who may act, and what evidence will establish that the action succeeded. It must also decide what people should learn from the work and how its benefits should be shared.The Information Age taught us to examine knowledge, networks, attention, power, and adaptation together. AI makes that combined view more useful. A company can reproduce more execution while preserving old delays, transferring hidden costs, or concentrating control. It can also use the new capacity to broaden participation and improve the work it actually completes.The future of corporate work will be shaped by how organizations turn abundant execution into outcomes that are useful, trustworthy, and accountable to the people they serve.That is a management choice, an architectural choice, and a choice about the kind of institution a corporation intends to be.", "content_html": "Imagine a company that can prepare an analysis in minutes. Its systems gather records, compare alternatives, draft recommendations, and assemble a presentation. The proposal still waits for someone to settle conflicting priorities, authorize spending, and accept responsibility for the decision.
The company has accelerated most of the work processes, but not the overall workflow. Whether it has become a better company depends on what happens next.
That is the central question of corporate work in the age of AI. The Information Age, which began to appear in the mid-20th century, made it easier to store, find, copy, and move information. AI extends the automation of interpreting that information and using it to perform tasks. When a useful procedure can be reproduced across many AI agents, an organization gains a different way to expand its capacity.
The consequences reach beyond individual productivity. They affect why companies have departments, how people learn, where authority belongs, what a finished job costs, and who benefits from the work.
My argument is that AI makes some forms of execution more abundant, increasing the importance of the systems that turn execution into accepted outcomes. The future corporation will need to combine reusable knowledge, bounded machine action, human judgment, and accountable decisions. Its success will depend on the design of that combination.
There is no single, agreed doctrine of the Information Age. Alvin and Heidi Toffler, Daniel Bell, Peter Drucker, Manuel Castells, and later writers described overlapping changes while disagreeing about their causes, desirability, and likely outcomes. The following summary groups the corporate implications of the broader Information Age transformation. These are named themes, rather than eighteen universally accepted laws. The writers listed are foundational contributors or particularly useful specialists for each subject; this is a reading map, not a ranking by publication volume.
| Information Age idea | What it describes | Leading contributors and major work |
|---|---|---|
| 1. Knowledge as a productive resource | Expertise and theoretical knowledge become central to production, alongside physical assets and labor. Organizations must convert knowledge into performance. | Daniel Bell, The Coming of Post-Industrial Society (1973); Peter Drucker, Post-Capitalist Society (1993) and his knowledge worker productivity research; Alvin and Heidi Toffler, Revolutionary Wealth (2006). |
| 2. Reusable knowledge and collective memory | Knowledge can be shared and reused without being consumed in the way a physical input is. Networks make distributed contributions useful to others. | The Tofflers on knowledge and wealth; Yochai Benkler, The Wealth of Networks (2006). |
| 3. Attention scarcity and information overload | More available information increases demands on the people receiving it. Filtering and allocating attention become organizational tasks. | Herbert A. Simon, “Designing Organizations for an Information-Rich World” (1971). |
| 4. Acceleration and institutional mismatch | Technology, social practices, and institutions change at different speeds. Faster tools can increase pressure rather than create free time. | Alvin Toffler, Future Shock (1970); Hartmut Rosa, Social Acceleration (English edition 2013); Carlota Perez, Technological Revolutions and Financial Capital (2002). |
| 5. Network enterprises and adaptive organization | Firms coordinate expertise, suppliers, and projects through networks. Flexible activity can coexist with concentrated decision-making. | Manuel Castells, The Information Age trilogy (1996–1998); Thomas W. Malone, The Future of Work (2004). |
| 6. Decentralized decisions and specialist autonomy | Knowledge work raises questions about who has the expertise to decide. In traditional organizations leaders decide. In information based organizations, experts decide, regardless of their elevation in the company. Technology expands the ways groups can coordinate decisions. | Drucker on knowledge worker productivity; Malone, Superminds (2018), on hierarchies, markets, democracies, and communities. |
| 7. Customization and the experience economy | Organizations serve varied needs through tailored products, services, and experiences. Customization can coexist with large production volumes. | B. Joseph Pine II and James H. Gilmore, Mass Customization and The Experience Economy (1999); Alvin Toffler, The Third Wave (1980). |
| 8. Flexible time and place of work | Telecommunications loosen the relationship between some work and a shared office. Some tasks need presence and contact while others do not. | Alvin Toffler, the “electronic cottage” in The Third Wave; Castells on networked time and space. |
| 9. Repeated learning and changing careers | Expertise needs renewal as work changes. Learning extends beyond a single period of formal education and beyond classrooms. | Drucker on knowledge work; Ivan Illich, Deschooling Society (1971), especially learning webs; Toffler on adaptation. |
| 10. Prosumers and peer production of products | Customers and users help produce, improve, or create the products they use. Productive collaboration can occur outside conventional employment. | Toffler on the prosumer; Benkler on peer production; Eric von Hippel, Democratizing Innovation (2005). |
| 11. Unpaid work and incomplete measures of value | Market transactions and company accounts leave out important contributions to overall value. A business can also reduce its own costs by transferring work to its customers. | Toffler on the unpaid economy; Mariana Mazzucato, The Value of Everything (2018); Daron Acemoglu and Simon Johnson on work transfer and automation. |
| 12. Data power and platform concentration | Distributed participation demands a more centeralized concentration of data and platforms controlled by a few, but more empowered gatekeepers. | Shoshana Zuboff, The Age of Surveillance Capitalism (2019); Nick Srnicek, Platform Capitalism. |
| 13. Technological choice and the distribution of gains | Higher productive capacity does not automatically produce broadly shared prosperity. Technology can complement people, replace tasks, or strengthen control over work. | Acemoglu and Johnson, Power and Progress (2023); Mazzucato on value creation and extraction. |
| 14. Identity and belonging under change | Flexible institutions and digital environments alter relationships, identity, and security. Adaptability has human consequences. | Zygmunt Bauman, Liquid Modernity (2000); Luciano Floridi, The Fourth Revolution (2014). |
| 15. Interdependence and system fragility | Connected systems contain feedback, delays, and dependencies. Improving one component can produce unexpected effects elsewhere. | Donella H. Meadows, Thinking in Systems (2008) and “Leverage Points”; the Tofflers on synchronization. |
| 16. Physical infrastructure and resource constraints | Communication depends on material systems. Energy, logistics, equipment, and environmental limits remain part of everyone’s economic value chain. | Jeremy Rifkin, The Third Industrial Revolution (2011) and The Zero Marginal Cost Society (2014); Meadows on systems and limits. |
| 17. Anticipatory governance and multiple futures | Institutions need ways to prepare for uncertainty and adjust their rules of governance and risk. Scenarios help examine assumptions before events settle them. | Peter Schwartz, The Art of the Long View (1991); Perez on technological and institutional transitions; Toffler on anticipation. |
| 18. Truth and the purposes of technology | Information systems shape what people recognize as knowledge, authority, and progress. Their usefulness requires standards beyond technical capability that reaches into epsitomology. | Neil Postman, Technopoly; Floridi on life within an information environment; Toffler on competing tests of truth. |
This foundation sets us up for the next transformation. However everything above in is tenstion. Networks can disperse activity while concentrating control. Customization can expand choice while intensifying measurement. Faster communication can increase the burden of coordination. A company can appear more productive because someone outside its accounts is doing more unpaid work.
The above helps us see the possibilities. Do not assume that every technical improvement produces an organizational or social improvement.
The starting list needs both extension and refinement. The principles below combine empirical findings, practical engineering lessons, and proposed rules for corporate design. Where a conclusion is a proposal or a forecast, I treat it as such.
Using AI well involves choosing an appropriate task, explaining the outcome, supplying relevant context, checking the result, and knowing when to stop or escalate. Familiarity with one interface is only part of that skill.
In Crucial Prompting, I described prompting as a communication practice. The Skill that Outgrows the Tool pushes the argument further: translating business problems into useful systems is more durable than memorizing a product’s controls.
The evidence also suggests that expertise and AI assistance interact. In Generative AI at Work, Erik Brynjolfsson, Danielle Li, and Lindsey Raymond found different effects across customer support workers, including larger gains for less experienced workers and evidence of learning. That study concerns a particular work setting; it does not establish a universal learning curve for every AI user.
The implication is a training proposal: teach problem definition, judgment, verification with validation, and workflow design together.
A response, a tool call, and a completed business action are outputs needed at different times, and in the past might be considered atomic products. Today, we recognize them as parts of a workflow that culminates in an accepted outcome. That accepted outcome needs a defined acceptance standard.
The Cost of a Finished Job makes the practical case for measuring the whole workflow. Sayash Kapoor and colleagues make a related research argument: agent evaluations need to consider cost alongside accuracy.
I propose:
Cost per accepted outcome = total attributable workflow cost ÷ outcomes that meet the agreed acceptance standard.
The numerator includes model and compute usage, data and tools, allocated design and integration work, human review, retries, rework, operational support, and expected residual failure costs. Failed attempts remain in the numerator. Avoid counting the same rework twice.
Quality, timeliness, purpose, and acceptable risk must be specified separately. A cheap outcome that causes unacceptable harm is a failed choice, even if its invoice is small.
An organization of people can scale by adding more individuals, but each person brings unique experience, relationships, and judgment that cannot be perfectly replicated. This generally takes months of time to onboard, develop, and integrate new team members effectively.
An organization that uses AIcan run additional instances of an agent and a configured workflow. It cannot reproduce an experienced person’s full history, relationships, and judgment by copying a file. However, if the organization has well designed processes, workflows, data definitions, accountaiblities, and defined avenues of autonomy, it can leverage replication to achieve scale.
This makes replication a consequential economic difference. It does not make copies free, independent, or automatically better. Each instance needs resources and a well thought out design. The danger is that a flawed design can propagate widely and it can affect all replicated instances.
Google’s research on agent scaling shows why task structure matters: parallel work can benefit from multiple agents, while sequential dependencies and coordination costs can undermine the gains. The useful proposition is conditional: replicate work where its additional accepted outcomes justify the additional resources. The ability to identify parallelizable tasks is a hard problem that is studied in both organizational theory and computer science.
Humans scale through hierarchy, teaching, specialization, and collaboration. Malone’s Superminds and Benkler’s peer production research describe others.
Agent systems scale through replication and task allocation, boundary definitions, shared states, and rules for combining results. Anthropic’s multi-agent research system, for example, uses an orchestrator and workers with defined assignments.
The relevant difference is how capacity can be reproduced and coordinated. A swarm still has an organizational design. The corporate question is which decisions belong to a person, a team, a rule, or a AI Agent for a particular kind of work. Some tasks are better suited for human judgment, while others can be efficiently handled by agents.
A system can perform one task well and fail on a nearby task that appears similar.
Fabrizio Dell’Acqua, Ethan Mollick, and their coauthors call this the jagged technological frontier. Their experiment with consultants found improvements on tasks within the tested model’s capabilities and worse performance on a task outside that frontier.
This argues for evaluating specific work rather than declaring that a model can replace an occupation you find in an industrial age company. Jobs contain tasks with different demands, dependencies, and consequences. Capability assessments also expire as models, tools, and work change.
All of this means is that job descriptions are going to change drastically as work is card sorted between humans and AI agents.
A model contributes gneral world knowldge. An agent knows a process. It also needs context, identity, permissions, tools, records, execution logic, and recovery.
The AI Value Stream examines that chain. The lesson is that an upgrade to any of those components, even a model upgrade, can leave the actual service unchanged when another component limits performance.
An impressive demonstration becomes an operating capability only after the surrounding system can deliver its promised outcome. You must evaluate the assembled service, including the people who operate, review and maintain it.
A corrected answer in one conversation does not necessarily improve every other agent instance. Organizations must deliberately capture, validate, and distribute useful corrections.
This is a design implication of reusable knowledge: collective memory should record sources, owners, effective dates, exceptions, and decisions. Teams need ways to remove obsolete information as well as add new information. If your organization does not have a process for removing old information or fixing errors, the value of the shared memory will degrade over time and is probably not AI ready now.
Knowledge Management is the core capability. Its value comes from reliable reuse. A larger archive alone does not establish that reliability.
Multiple agents agreeing can reflect a shared source or a shared error. Fluent prose does not establish that an action was correct.
When AI Moves Faster Than the Organization distinguishes system capability from the appearance of coordinated activity. My design rule is to use verification appropriate to the consequence: original records for factual claims, execution tests for software behavior, reconciliation for financial records, and qualified review where judgment is required.
Another AI can assist with checking. It should be evaluated as a checker, rather than assumed to provide independent confirmation.
A system may be capable of acting with little supervision while lacking permission to make a particular commitment.
Corporate design must specify what it may access, change, spend, disclose, and approve; when it must escalate; and which human or institution remains accountable. These decisions belong with the workflow.
The distinctions in When AI Moves Faster Than the Organization are useful here: throughput, intelligence, autonomy, authority, and business value describe different properties. Increasing one does not prove that the others increased.
When preparation becomes faster, the limiting work may move to review, prioritization, approval, or delivery.
When Output Becomes Abundant frames this as a shift toward judgment, alignment, and trust. I treat that as a useful forecast to test, rather than a universal description of every workplace.
Corporate measurement should follow the entire outcome. If faster drafting merely fills a reviewer’s queue, the organization has moved its waiting time. The next improvement must address that queue and the reasons decisions wait.
Switching model providers is one kind of portability. Preserving quality, controls, operating evidence, and cost while moving a business process is a larger undertaking.
Model Portability Is Not AI Portability argues for control over the workflow contract, evaluations, identity and authorization, records of operation, and recovery arrangements.
The proposed principle is to make important capabilities replaceable at the system level. Otherwise, apparent model choice can conceal dependence on a provider’s surrounding infrastructure.
AI can assist learning and expand participation. It can also remove tasks through which novices acquire experience, increase surveillance, or concentrate gains.
Which result follows depends partly on how the organization designs work and allocates benefits. Acemoglu and Johnson’s argument for technology that complements workers supplies an economic foundation. Beyond the Mirror supplies the normative direction: shared purpose, a living commons, coordinated autonomy, and shared capability gains.
I propose treating learning opportunities, employee voice, and the distribution of benefits as explicit decisions. Their value should enter the design before the organization counts its savings.
The table below is my synthesis of the preceding arguments. These are proposed implications and choices, rather than predictions attributed to the earlier writers. Each row connects an Information Age theme to the AI principles.
If I were to pick the top three changes that deserve particular attention.
First, the scarcity changes. Access to an answer can become easier while reliable context, attention, authority, or physical delivery remain scarce.
Second, the unit of organization changes. Headcount becomes a less complete account of execution capacity when a team can reproduce software workflows. The work still belongs within institutions that resolve conflicts and accept consequences.
Third, the distribution question becomes more urgent. Broad access to useful tools can coexist with narrow ownership of the infrastructure and the gains. Participation, decision rights, and ownership must be examined separately.
| Information Age idea | What AI changes | Recommendations |
|---|---|---|
| 1. Knowledge as a productive resource | Some applications of expertise can be reproduced in software. Useful results still depend on context and evaluation. | Invest in the system that applies knowledge, and preserve the expertise needed to judge it. |
| 2. Reusable knowledge and collective memory | Shared knowledge can guide many executing instances. A stale rule can also spread widely. | Maintain sources, versions, corrections, and permissions as part of the operating capability. |
| 3. Attention scarcity and information overload | Generating more analysis becomes easier. Review and decision capacity can become limiting inputs. | Measure demands on recipients and route only information that serves a decision or action. |
| 4. Acceleration and institutional mismatch | Execution can outpace policy, procurement, training, and approval. | Match deployment speed to the organization’s capacity to govern and absorb the work. |
| 5. Network enterprises and adaptive organization | Teams can add temporary machine capacity around a task. Dependencies and coordination costs still shape the result. | Organize execution around actual work dependencies and bounded assignments. |
| 6. Decentralized decisions and specialist autonomy | Expertise becomes more accessible, while tools can also centralize control. | Allocate decision rights explicitly, with limits and accountable owners. |
| 7. Customization and the experience economy | Tailoring information and some services can become cheaper. Tailored content can also overwhelm or manipulate. | Evaluate customer benefit and consent alongside the economics of personalization. |
| 8. Flexible time and place of work | Agents can continue bounded work across locations and hours. People can face expanded expectations of availability. | Design handoffs, escalation windows, and protected time for human workers. |
| 9. Repeated learning and changing careers | Assistance can support learning; automation can remove practice opportunities. | Retain apprenticeships, supervised responsibility, and ways to assess skill without assistance. |
| 10. Prosumers and peer production | More users may create tools, analyses, and services themselves. Infrastructure ownership can remain concentrated. | Support participation and clarify ownership, support obligations, and exit options. |
| 11. Unpaid work and incomplete measures of value | Apparent savings can hide review and repair performed elsewhere. | Track total workflow burdens and accepted outcomes, including work transferred to others. |
| 12. Data power and platform concentration | More activity can flow through providers that supply models, tools, and coordination. | Preserve appropriate control over records, permissions, evaluations, and process portability. |
| 13. Technological choice and the distribution of gains | Greater capacity expands the choices about displacement, augmentation, and rewards. | Decide how benefits support pay, development, service quality, reduced burdens, or new capabilities. |
| 14. Identity and belonging under change | Familiar tasks and signals of expertise can change quickly. | Give people meaningful participation, continuity, and a role in defining successful work. |
| 15. Interdependence and system fragility | Fast actions can propagate mistakes through connected processes. | Bound actions, monitor downstream effects, and build recovery and independent checks. |
| 16. Physical infrastructure and resource constraints | Replicated execution increases demand for compute and supporting infrastructure; physical delivery retains its own limits. | Include capacity, resource use, and physical dependencies in service economics and planning. |
| 17. Anticipatory governance and multiple futures | Rapidly changing capability makes fixed assumptions less reliable. | Use scenarios, staged deployments, review dates, and reversible commitments where possible. |
| 18. Truth and the purposes of technology | Persuasive output can be produced at scale. Its volume does not establish its validity or social value. | Require evidence, contestability, and a clear account of whose purpose the work serves. |
The strongest forecast concerns roles organized mainly around repeatable information handling. As reliable automation improves, companies may place less emphasis on manually producing standard artifacts and more on defining, verifying, and delivering the outcomes those artifacts support.
The ILO and NASK’s 2025 occupational exposure study identifies clerical occupations as particularly exposed and emphasizes that most occupations contain tasks requiring human input. Exposure describes technical potential; it does not establish adoption, layoffs, or the disappearance of a profession.
The following list is my conditional forecast of corporate work redesign. It assumes that a company can meet its acceptance and risk standards at a worthwhile total cost. Demand, regulation, customer preferences, and new services can change staffing in either direction.
| Types of jobs likely to receive less emphasis in their current form | Work likely to be deemphasized | Outcomes that become more important |
|---|---|---|
| Data entry clerks and routine administrative processors | Copying records, transcribing standard forms, and moving information between systems. | Accurate, timely records; resolved exceptions; traceable corrections. |
| Reporting analysts and presentation production staff | Assembling recurring dashboards, summarizing familiar data, and formatting slides. | A supported decision, a clear explanation of uncertainty, and follow-through on the decision. |
| First line customer service and internal help desk staff | Answering standard questions, locating policies, and routing familiar requests. | Verified resolution, customer understanding, and effective handling of difficult or sensitive cases. |
| Software developers focused on routine implementation | Writing standard boilerplate, straightforward transformations, and familiar integrations. | Maintainable software that meets real requirements and works safely within its larger system. |
| Testers focused on repetitive manual checks | Repeating standard test steps and preparing routine test artifacts. | Evidence that important behavior works, including failure cases and interactions between systems. |
| Research assistants and document review analysts | Gathering sources, extracting fields, and preparing first summaries of familiar material. | Reliable evidence, identification of conflicting findings, and an argument that survives scrutiny. |
| Content writers producing generic marketing material | Creating routine copy variations, standard product descriptions, and undifferentiated summaries. | Distinctive communication that is accurate, useful to its audience, and consistent with the organization’s commitments. |
| Bookkeeping and finance operations staff handling standard transactions | Coding familiar transactions, extracting invoice fields, and preparing routine reconciliations. | Correct accounts, resolved discrepancies, and evidence supporting authorized transactions. |
| Recruiting coordinators and staff performing preliminary screening | Scheduling interviews, formatting candidate records, and summarizing applications against stated criteria. | A fair, documented hiring process with accountable decisions and meaningful candidate communication. |
| Compliance staff focused on document assembly | Retrieving standard policies, mapping familiar requirements, and drafting routine evidence packages. | Demonstrated compliance, identified gaps, and a defensible account of how obligations were met. |
| Project coordinators focused on status collection | Chasing updates, compiling meeting notes, and maintaining routine schedules. | Dependencies resolved, commitments kept, and risks addressed before they obstruct delivery. |
| Management roles dominated by information relay | Passing status upward, distributing standard instructions, and assembling reports from other reports. | Priorities settled, resources allocated, people developed, and decisions owned. |
| Training staff producing standard course material | Drafting generic lessons, quizzes, and summaries. | Demonstrated capability, useful feedback, and a path from beginner practice to independent responsibility. |
| Procurement and logistics staff focused on routine planning | Comparing standard offers, preparing documents, and drafting familiar schedules. | Authorized purchases and reliable physical delivery, with supplier, capacity, and operational risks managed. |
Several of these jobs already include substantial judgment and relationship work. Their titles may remain while their task mix changes. The forecasting claim applies most strongly where routine production dominates the role.
The outcomes also need clear measures. “A supported decision” means someone can identify the evidence, the alternatives, and the accountable decision-maker. “Verified resolution” means the issue is actually resolved for the person affected. “Reliable delivery” includes the physical result, rather than a completed planning document.
To produce those outcomes, companies need repeatable processes that connect intention, execution, evidence, and responsibility. The table is a proposed operating framework; it applies across the job types above.
| Process | What it needs to accomplish | Skills needed |
|---|---|---|
| Outcome definition and acceptance | Agree on the need, constraints, evidence of completion, service timing, and unacceptable risks before execution. | Problem framing, domain expertise, clear writing, customer understanding, and negotiation. |
| Workflow design and delegation | Separate independent tasks from dependent decisions; allocate work to people, agents, and established software. | Process analysis, systems thinking, AI fluency, task decomposition, and coordination. |
| Context and knowledge maintenance | Keep authoritative information accessible, current, permissioned, and correctable. | Information architecture, data stewardship, source evaluation, and documentation. |
| Evaluation and verification | Test the service against real cases, inspect failures, and check that evidence supports the claimed outcome. | Experimental design, statistical reasoning, software testing, critical thinking, and professional judgment. |
| Authorization and accountable action | Bound access and commitments, provide escalation, and keep an understandable record of decisions and actions. | Governance design, risk assessment, security literacy, ethical reasoning, and decision-making. |
| Exception handling and recovery | Recognize unusual situations, involve appropriate people, restore service, and learn from failures. | Diagnosis, troubleshooting, incident response, adaptability, and communication under pressure. |
| Economics and continuous improvement | Measure total cost per accepted outcome, locate bottlenecks, and check who bears the remaining burden. | Financial literacy, measurement, causal reasoning, capacity planning, and supplier evaluation. |
| Learning and collaborative development | Preserve practice, coach people, resolve disagreements, and ensure that improvements expand useful human capability. | Teaching, feedback, facilitation, relationship building, conflict resolution, and change leadership. |
These needs suggest growing responsibilities for outcome owners, enterprise architects, evaluation specialists, knowledge stewards, service reliability teams, and educators. Organizations may assign them to existing roles or create new ones. They are proposed responsibilities, rather than a promise that a particular new title will become common.
The most basic way to say this is that the essential skill is the ability to connect a real need to a reliable result while working with other people. AI fluency becomes part of that capability. Technical and domain knowledge remain necessary to understand the system, recognize its limits, and challenge its output.
These implications suggest an operating model. They do not imply that every company needs fewer employees, fewer departments, or a swarm of agents.
Take a hypothetical supplier review. Researching several suppliers can happen in parallel. Resolving conflicting contract terms, approving a purchase, and committing funds depend on earlier findings and authorized decisions.
The useful structure is a workflow that reflects those dependencies. Each assignment needs a defined outcome, relevant sources, constraints, an acceptance test, and an escalation path. A shared record should show what happened and what remains uncertain.
A department chart helps identify responsibility. A map of the work helps determine where execution can proceed independently, where results must be combined, and where action must wait.
AI increases the value of having both.
Where a managerial layer primarily relays information, automation may change its workload. Managers also resolve competing aims, allocate resources, develop people, negotiate obligations, and accept responsibility.
My forecast is that those functions become more visible when routine preparation is easier. The organization should evaluate a layer by the decisions and commitments it contributes, rather than assume that an agent can inherit its role.
This is also why replacing reporting meetings with automated reports may achieve little. The unresolved issue may be a disagreement about priorities. A system can present the disagreement clearly; someone still needs legitimate authority to settle it.
Senior judgment has a production history. People develop it by attempting work, seeing consequences, receiving feedback, and taking progressively greater responsibility.
If an organization automates all of a novice’s early work, it should examine how that person will gain experience. A proposed alternative is to use AI for coaching and comparison while preserving meaningful practice: explain an answer, challenge its evidence, perform selected tasks independently, and own bounded decisions under supervision.
The relevant question is whether today’s efficient workflow also produces tomorrow’s capable colleagues.
Agents Don’t Click argues that software increasingly needs to support operators that are machines. The title is a provocation: agents can use graphical interfaces, and people still need useful ones.
The corporate implication I draw is to expose important actions through clear, authorized operations with reliable records. People need ways to inspect, intervene, and challenge those actions. Both forms of access belong to the same governed service.
This makes business rules, permissions, and evidence of execution strategic assets. A polished screen is one way to use that service; an agent may use another.
Beyond the Mirror describes a corporation organized around shared purpose, a living commons, coordinated autonomy, and shared gains. Those principles can become operating decisions.
Shared purpose means the people affected can help define useful outcomes. A living commons means knowledge has maintainers and a correction process. Coordinated autonomy means freedom within understood responsibilities and limits. Shared gains means the company makes explicit choices about how improvements benefit the people contributing to them.
An organization can put those choices into budgets, roles, learning opportunities, and measures of service quality. Faster execution makes their absence harder to excuse.
Return to the imagined company whose analysis arrives in minutes.
Its next step is to determine what the analysis supports, whose needs matter, who may act, and what evidence will establish that the action succeeded. It must also decide what people should learn from the work and how its benefits should be shared.
The Information Age taught us to examine knowledge, networks, attention, power, and adaptation together. AI makes that combined view more useful. A company can reproduce more execution while preserving old delays, transferring hidden costs, or concentrating control. It can also use the new capacity to broaden participation and improve the work it actually completes.
The future of corporate work will be shaped by how organizations turn abundant execution into outcomes that are useful, trustworthy, and accountable to the people they serve.
That is a management choice, an architectural choice, and a choice about the kind of institution a corporation intends to be.
", "url": "https://tedt.org/The-Future-of-Corporate-Work/", "image": "/img/2026-10/Human Judgment Through the Red Aperture.webp", "tags": ["future of work","Information Age","AI agents","AI governance","human judgment","operating model","accepted outcomes"], "date_published": "2026-10-03T00:00:00-07:00", "date_modified": "2026-10-03T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/This-Isnt-a-Storm-This-Is-the-Weather/", "title": "This Isn't a Storm. This Is the Weather.", "summary": "We are preparing for a storm when we should be learning to operate in the new weather.", "content_text": "Sophocles was a playwright in fifth-century BCE Athens, whose tragedies explored the difficult choices people make when duty, loyalty, and power collide. Nearly 2,500 years later, those choices remain familiar. His play Antigone begins after a battle for Thebes. Antigone, the principal character’s two brothers have died fighting on opposite sides, and their uncle, King Creon, has ordered that one be denied burial. Antigone defies the king, believing her obligation to her brother outweighs the decree. The king condemns her to death. The Prince, Haemon, who is engaged to Antigone, comes to persuade his father to reconsider. Their conversation becomes an argument about leadership: whether a person in authority can listen, learn, and change a decision during changing times without looking weak and treating that accommodation as a surrender.During the discussion Haemon offers the example of a sailor who keeps the sail pulled tight and refuses to loosen it, until the boat overturns. Experience and determination can only carry us so far when we refuse to adjust to the conditions around us. The wind does not become more agreeable because the person holding the ropes is certain they are right.I think about that when I hear people describe what AI is bringing into our organizations. A storm of new code. A storm of patches. A storm of generated images, documents, and “AI slop” that someone still has to sort through. Calling these things storms carries an assumption: eventually, they will pass, we will catch up, and work will return to normal. But the ability to produce all of this faster and more cheaply will still be there when we finish today’s backlog. More code creates more maintenance obligations. More content creates more work deciding what deserves our attention and trust. These are becoming the conditions under which we work. We are preparing for a storm when we should be learning to operate in the new weather.That means adapting the whole process. If we accelerate creation, we also need to improve how we review, test, patch, maintain, and retire what we create. We need to decide what is worth producing in the first place. Asking the same people to absorb an ever-growing volume through extraordinary effort is a poor plan for ordinary operations. Back in Antigone, Haemon asks his father, the king, to remain willing to learn. His sailor gives us something concrete to remember: keeping the boat on its journey requires adjusting the sail. We should build that adjustment into the way we work, because this weather is now part of the journey.Keep this in mind when you are thinking if the chaos we are experiencing is a one time event or if this is just the weather. I believe that this isn’t a storm. This is now weather. This is just the normal we need to operate within, and like the sailor, the prince, and the king, we all need to adapt or we will definitely look weak, foolish, and unprepared for the conditions we face.", "content_html": "Sophocles was a playwright in fifth-century BCE Athens, whose tragedies explored the difficult choices people make when duty, loyalty, and power collide. Nearly 2,500 years later, those choices remain familiar. His play Antigone begins after a battle for Thebes. Antigone, the principal character’s two brothers have died fighting on opposite sides, and their uncle, King Creon, has ordered that one be denied burial. Antigone defies the king, believing her obligation to her brother outweighs the decree. The king condemns her to death. The Prince, Haemon, who is engaged to Antigone, comes to persuade his father to reconsider. Their conversation becomes an argument about leadership: whether a person in authority can listen, learn, and change a decision during changing times without looking weak and treating that accommodation as a surrender.
During the discussion Haemon offers the example of a sailor who keeps the sail pulled tight and refuses to loosen it, until the boat overturns. Experience and determination can only carry us so far when we refuse to adjust to the conditions around us. The wind does not become more agreeable because the person holding the ropes is certain they are right.
I think about that when I hear people describe what AI is bringing into our organizations. A storm of new code. A storm of patches. A storm of generated images, documents, and “AI slop” that someone still has to sort through. Calling these things storms carries an assumption: eventually, they will pass, we will catch up, and work will return to normal. But the ability to produce all of this faster and more cheaply will still be there when we finish today’s backlog. More code creates more maintenance obligations. More content creates more work deciding what deserves our attention and trust. These are becoming the conditions under which we work. We are preparing for a storm when we should be learning to operate in the new weather.
That means adapting the whole process. If we accelerate creation, we also need to improve how we review, test, patch, maintain, and retire what we create. We need to decide what is worth producing in the first place. Asking the same people to absorb an ever-growing volume through extraordinary effort is a poor plan for ordinary operations. Back in Antigone, Haemon asks his father, the king, to remain willing to learn. His sailor gives us something concrete to remember: keeping the boat on its journey requires adjusting the sail. We should build that adjustment into the way we work, because this weather is now part of the journey.
Keep this in mind when you are thinking if the chaos we are experiencing is a one time event or if this is just the weather. I believe that this isn’t a storm. This is now weather. This is just the normal we need to operate within, and like the sailor, the prince, and the king, we all need to adapt or we will definitely look weak, foolish, and unprepared for the conditions we face.
", "url": "https://tedt.org/This-Isnt-a-Storm-This-Is-the-Weather/", "image": "/img/2026-09/Weather-vs-Storm.webp", "tags": ["Sophocles","Antigone","leadership","organizational change","AI adoption","operating model","adaptability"], "date_published": "2026-09-28T00:00:00-07:00", "date_modified": "2026-09-28T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/When-AI-Moves-Faster-Than-the-Organization/", "title": "When AI Moves Faster Than the Organization", "summary": "We should evaluate the capability of the organization we are assembling around AI, including the people who remain responsible for its work.", "content_text": "My daughter Hannah saved for months to buy a Lego Tuxedo Cat. When it arrived, she had the pieces, the instructions, and a great deal of enthusiasm. She also discovered that a complicated model could ask more of her than she had expected.She turned to her brother and sister and me for help. We had built similar models before. Our experience gave her another way to approach the work, and her confidence grew as she learned. I wrote about that experience as a lesson in helping people through change.Lately, I have been thinking about it as a lesson in how we recognize progress.You could count pieces handled, pages read, or the number of people helping. Each might tell you something useful. None would establish that the next assembly fit where it belonged. For that, you would have to look at what was being built.That distinction is becoming important in enterprise AI. We are acquiring more capable models, giving them tools, and arranging them into teams. We need to understand what the resulting organization can accomplish, where its work gets stuck, and what evidence should cause us to change the plan.The paper From AGI to ASI, by Tim Genewein and colleagues, gives us a reason to examine those questions. It considers how artificial general intelligence might develop beyond human-level performance. Its definition of superintelligence is demanding: a system whose cognitive abilities exceed those of large groups of human experts across virtually all domains.Among its possible pathways is collective intelligence. Many coordinated AI agents might achieve capabilities beyond those of any individual member. The authors also examine scaling, algorithmic change, and recursive improvement. These pathways could interact. They remain uncertain, and the paper does not establish an inevitable transition or a reliable arrival date.For an enterprise architect, the collective possibility has an immediate implication. We should evaluate the capability of the organization we are assembling around AI, including the people who remain responsible for its work.Capability belongs to the working systemA model can answer a question about a supplier. A working procurement system must establish which supplier we mean, retrieve the relevant records, recognize a conflict in those records, apply the right policy from the document desk procedures, and leave evidence someone can examine and audit. You may also need to stop, find the right person, and ask that person to resolve a disagreement.It’s that information, documented, repeatable, and measured, in the system, that enables the system to work effectively.All of this applies when you add AI agents to the mix, except now you also have to make all that information available to them in a usable format as well. Giving one agent research, another analysis, and a third review creates a division of labor. Whether that division helps depends on the task, the information they share, and how their results are reconciled. Three agents repeating the same unsupported assumption have given us three versions of the same problem.The DeepMind Institute essay Artificial Symbiotic Intelligence develops this institutional view. Its authors argue that capability may emerge through arrangements of models, tools, people, and governing structures. It is a conceptual argument about a possible future. We still need experiments that show which arrangements work.There is relevant empirical evidence. Towards a Science of Scaling Agent Systems examines 260 configurations across six benchmarks. Relative to single-agent baselines, results range from an 80.8 percent improvement on decomposable financial reasoning to a 70 percent decline on sequential planning. Those findings apply to the tested systems and tasks. They demonstrate why adding agents requires an architectural decision about the work.I would therefore ask a team proposing an agent workforce to show its dependencies. All of them. They need to demonstrate which tasks can proceed independently. Where must one result be correct before the next action begins? What happens when two agents disagree? Who can tell whether the final answer rests on evidence or on repeated agreement?These questions give us something concrete to design. They also give us something to test when a new model arrives and changes things. A stronger model may make a particular review step unnecessary, or expose a weakness elsewhere. We need to know which happened.Be precise about what improvedAI discussions that I participate in compress several changes into the word “better.” That makes it difficult to decide what to fund or authorize. I would keep four questions visible.Throughput asks how much acceptable work the system completes in a given period. Producing more drafts can help, but we also need to count how many become usable results and how long they wait along the way.Intelligence asks whether the system can handle harder or unfamiliar problems. Completing more examples of a familiar task does not, by itself, demonstrate that broader capability.Autonomy asks how much work the system can carry without intervention. That requires recording the help it receives, including corrections and cleanup after it reports completion. The authority we grant it remains a separate decision.Business value asks what changed for the organization and the people it serves. Lower cost, shorter waits, fewer errors, or a service that becomes possible for the first time can all matter. Their importance depends on the purpose of the work.The distinction is visible in NVIDIA’s recent SoL-Pi research. On its 51-task EdgeBench evaluation, the researchers report comparable performance to the Pi coding harness while reducing recorded token traffic by roughly 45 to 49 percent and API cost by about a third. The improvements came from the surrounding execution system. That is evidence of greater efficiency under the reported conditions. It does not establish a corresponding increase in general intelligence or savings across every business workflow.A team could make a worthwhile investment on exactly that basis. We do not need to turn every efficiency gain into a claim about workforce replacement, general intelligence, or superintelligence to justify it.In The Cost of a Finished Job, I argued for measuring cost per accepted outcome. That measure includes the work people perform around the machine: review, correction, support, and recovery. It also forces us to define acceptance before we celebrate production.If two configurations finish the same work at the same quality, and one requires less money and less supervision, we have learned something useful. If one handles previously unsolvable cases but costs more, we have learned something different. A single adoption score would hide the decision we need to make.Follow the work to its next constraintOnce a task becomes faster, the rest of the process receives its output sooner. That can shorten delivery. It can also create a queue somewhere else.Anthropic provides a concrete example in its September 14, 2026 account of agentic coding straining continuous integration. The company reports a 25-fold increase in CI jobs over six months. Its service for selecting relevant tests struggled to keep up. Three successive fixes lasted 70 days, 29 days, and less than a day before the team moved to a more scalable design.This is Anthropic reporting on its own environment. Its growth rate is not a forecast for every engineering organization. But the account illustrates a failure mode worth testing for: accelerated production can overwhelm the machinery used to establish whether the work is ready.The responses also cost more to operate. Solving a bottleneck can improve the service while increasing expenses. We need to measure the whole result before declaring either success or waste.For people who work in companies that have a robust physical component to their value stream, such as the utility I work for, this is easy to recognize. An AI system might prepare an engineering planning package faster. Components still have to be manufactured and delivered. A crew still needs access to the site. The heavy equiptment to do the work, still needs to routed to the work location. And someone still has to establish that the work can proceed safely. Improved analysis can help with those constraints, but generating the analysis does not move the atoms around in the real world, nor create complete the actual change in reality.Some delays deserve to be removed. Others contain essential steps that need to remain to ensure safety and to allow for human judgement in order to avoid a consequential mistake. Calling every delay “friction” makes it too easy to treat them as interchangeable.The people with boots on the ground will help you distinguish between them. They know when an approval catches a real issue and when it merely sends the same information to another inbox. They also know which unofficial repair keeps a supposedly automated process running.I explored this movement of scarce work in When Output Becomes Abundant. The practical next step for almost every organization I have observed is to make all of this more visible. Measure time spent working, waiting, reviewing, and repairing. Follow a sample of jobs until the intended outcome occurs. Include the cases that fail, get abandoned, or return later with a problem.Otherwise, an impressive productivity gain in one department can become an unmeasured burden in another. All too often, I have seen cases where someone wants to automate a task to benefit some local maximum while negatively impacting the enterprise as a whlie. In such situations, the costs and delays shift and potentially multiply rather than disappear, creating friction that can undermine the overall efficiency of the organization.Give each scenario evidence that could change itThis is where scenario planning becomes useful. An organization needs several plausible accounts of how its work could change with the introduction of AI, with observations that would help distinguish between them.Suppose model capability improves slowly, while lower costs and better tooling make familiar tasks economical to automate. That future favors careful workflow engineering. We would look for stable quality at lower total cost and sustained reductions in human effort.Suppose coordinated systems begin completing longer, more difficult assignments reliably. That future could justify changes to roles and delegated responsibility. We would need evidence from complete assignments, including exceptions, recovery, and performance on work that differs from the examples used to tune the system.Suppose generation accelerates while verification, integration, or physical delivery remains constrained. That future calls for investment in the limiting stages. Rising queues, older unfinished work, repeated corrections, and delayed customer outcomes would be signals to investigate.These possibilities can coexist. Software maintenance, procurement, and field engineering may develop at different rates inside the same company. An enterprise-wide label for AI maturity would conceal those differences.Each scenario should connect to a decision. What would persuade us to expand delegation? What would cause us to invest in testing capacity? What result would tell us to stop adding agents and simplify the workflow? Which commitment would be expensive to reverse if our assumptions proved wrong?Set thresholds before the pilot. A team should agree on acceptable quality, cost, intervention, and recovery requirements while it can still discuss them without defending a rollout. The thresholds will differ by class of work and consequence.In How Much Work Can Your AI Safely Own?, I distinguished capability, evidence, and authority. Demonstrated ability contributes to a decision about responsibility. It does not make that decision for us.Collect evidence that can survive a change of mindSo how would you begin; I would begin with one important class of work and its current baseline. Record the time, cost, quality, and human effort required today. Then compare the proposed AI arrangement on representative cases, including difficult exceptions.Keep the model version, instructions, tools, permissions, and relevant data changes with the results. If several of those change together, be careful about attributing the improvement to one of them. Preserve failed attempts and escalations alongside successes, with access and retention appropriate to the information involved. If you do not track that information, or you fail to account for this, you will not have a reliable basis for evaluating progress.This also means you should track the consequences after acceptance too. A support case that reopens, a code change that requires repair, or a document that creates confusion downstream is a type of failure that belongs in the evaluation. The reporting boundary should follow the processes already established lines of responsibility starting with the customers request all the way to the customer getting their need answered. In other words, the full and complete Value Stream should be considered when evaluating the impact of AI on work.This evidence collection needs an owner and a place in ordinary operations. The development team that’s building the solution needs to have access to it. The operational teams that are supporting the technology need to have access to it. Every relevant team should review it often enough to act before a growing queue or recurring error becomes normal. Material changes to the model, workflow, or workload should trigger another look at the assumptions behind the plan.The purpose is to make changing course less expensive. We should be able to discover that one agent works better than five, that a stronger model earns its higher price, or that an apparently successful automation moved too much work onto someone else. Each finding should have a route into a decision.The part of Hannah’s Lego project I keep returning to is her willingness to change how she approached it. The instructions were available from the beginning. Progress also involved recognizing when help would be useful and learning how to use the experience around her.There are limits to the comparison. A Lego set comes with a known design. An enterprise adopting AI is still discovering some of what it can build. That makes it even more important to examine the work as it takes shape and to preserve what we learn.Hannah had saved for a cat she wanted to build. My help mattered because it supported that purpose and her growing ability to carry it forward. When we decide how to organize AI at work, I want us to keep an equally clear view of the people we are helping, the outcome they need, and the evidence that we are getting closer to it.", "content_html": "My daughter Hannah saved for months to buy a Lego Tuxedo Cat. When it arrived, she had the pieces, the instructions, and a great deal of enthusiasm. She also discovered that a complicated model could ask more of her than she had expected.
She turned to her brother and sister and me for help. We had built similar models before. Our experience gave her another way to approach the work, and her confidence grew as she learned. I wrote about that experience as a lesson in helping people through change.
Lately, I have been thinking about it as a lesson in how we recognize progress.
You could count pieces handled, pages read, or the number of people helping. Each might tell you something useful. None would establish that the next assembly fit where it belonged. For that, you would have to look at what was being built.
That distinction is becoming important in enterprise AI. We are acquiring more capable models, giving them tools, and arranging them into teams. We need to understand what the resulting organization can accomplish, where its work gets stuck, and what evidence should cause us to change the plan.
The paper From AGI to ASI, by Tim Genewein and colleagues, gives us a reason to examine those questions. It considers how artificial general intelligence might develop beyond human-level performance. Its definition of superintelligence is demanding: a system whose cognitive abilities exceed those of large groups of human experts across virtually all domains.
Among its possible pathways is collective intelligence. Many coordinated AI agents might achieve capabilities beyond those of any individual member. The authors also examine scaling, algorithmic change, and recursive improvement. These pathways could interact. They remain uncertain, and the paper does not establish an inevitable transition or a reliable arrival date.
For an enterprise architect, the collective possibility has an immediate implication. We should evaluate the capability of the organization we are assembling around AI, including the people who remain responsible for its work.
A model can answer a question about a supplier. A working procurement system must establish which supplier we mean, retrieve the relevant records, recognize a conflict in those records, apply the right policy from the document desk procedures, and leave evidence someone can examine and audit. You may also need to stop, find the right person, and ask that person to resolve a disagreement.
It’s that information, documented, repeatable, and measured, in the system, that enables the system to work effectively.
All of this applies when you add AI agents to the mix, except now you also have to make all that information available to them in a usable format as well. Giving one agent research, another analysis, and a third review creates a division of labor. Whether that division helps depends on the task, the information they share, and how their results are reconciled. Three agents repeating the same unsupported assumption have given us three versions of the same problem.
The DeepMind Institute essay Artificial Symbiotic Intelligence develops this institutional view. Its authors argue that capability may emerge through arrangements of models, tools, people, and governing structures. It is a conceptual argument about a possible future. We still need experiments that show which arrangements work.
There is relevant empirical evidence. Towards a Science of Scaling Agent Systems examines 260 configurations across six benchmarks. Relative to single-agent baselines, results range from an 80.8 percent improvement on decomposable financial reasoning to a 70 percent decline on sequential planning. Those findings apply to the tested systems and tasks. They demonstrate why adding agents requires an architectural decision about the work.
I would therefore ask a team proposing an agent workforce to show its dependencies. All of them. They need to demonstrate which tasks can proceed independently. Where must one result be correct before the next action begins? What happens when two agents disagree? Who can tell whether the final answer rests on evidence or on repeated agreement?
These questions give us something concrete to design. They also give us something to test when a new model arrives and changes things. A stronger model may make a particular review step unnecessary, or expose a weakness elsewhere. We need to know which happened.
AI discussions that I participate in compress several changes into the word “better.” That makes it difficult to decide what to fund or authorize. I would keep four questions visible.
Throughput asks how much acceptable work the system completes in a given period. Producing more drafts can help, but we also need to count how many become usable results and how long they wait along the way.
Intelligence asks whether the system can handle harder or unfamiliar problems. Completing more examples of a familiar task does not, by itself, demonstrate that broader capability.
Autonomy asks how much work the system can carry without intervention. That requires recording the help it receives, including corrections and cleanup after it reports completion. The authority we grant it remains a separate decision.
Business value asks what changed for the organization and the people it serves. Lower cost, shorter waits, fewer errors, or a service that becomes possible for the first time can all matter. Their importance depends on the purpose of the work.
The distinction is visible in NVIDIA’s recent SoL-Pi research. On its 51-task EdgeBench evaluation, the researchers report comparable performance to the Pi coding harness while reducing recorded token traffic by roughly 45 to 49 percent and API cost by about a third. The improvements came from the surrounding execution system. That is evidence of greater efficiency under the reported conditions. It does not establish a corresponding increase in general intelligence or savings across every business workflow.
A team could make a worthwhile investment on exactly that basis. We do not need to turn every efficiency gain into a claim about workforce replacement, general intelligence, or superintelligence to justify it.
In The Cost of a Finished Job, I argued for measuring cost per accepted outcome. That measure includes the work people perform around the machine: review, correction, support, and recovery. It also forces us to define acceptance before we celebrate production.
If two configurations finish the same work at the same quality, and one requires less money and less supervision, we have learned something useful. If one handles previously unsolvable cases but costs more, we have learned something different. A single adoption score would hide the decision we need to make.
Once a task becomes faster, the rest of the process receives its output sooner. That can shorten delivery. It can also create a queue somewhere else.
Anthropic provides a concrete example in its September 14, 2026 account of agentic coding straining continuous integration. The company reports a 25-fold increase in CI jobs over six months. Its service for selecting relevant tests struggled to keep up. Three successive fixes lasted 70 days, 29 days, and less than a day before the team moved to a more scalable design.
This is Anthropic reporting on its own environment. Its growth rate is not a forecast for every engineering organization. But the account illustrates a failure mode worth testing for: accelerated production can overwhelm the machinery used to establish whether the work is ready.
The responses also cost more to operate. Solving a bottleneck can improve the service while increasing expenses. We need to measure the whole result before declaring either success or waste.
For people who work in companies that have a robust physical component to their value stream, such as the utility I work for, this is easy to recognize. An AI system might prepare an engineering planning package faster. Components still have to be manufactured and delivered. A crew still needs access to the site. The heavy equiptment to do the work, still needs to routed to the work location. And someone still has to establish that the work can proceed safely. Improved analysis can help with those constraints, but generating the analysis does not move the atoms around in the real world, nor create complete the actual change in reality.
Some delays deserve to be removed. Others contain essential steps that need to remain to ensure safety and to allow for human judgement in order to avoid a consequential mistake. Calling every delay “friction” makes it too easy to treat them as interchangeable.
The people with boots on the ground will help you distinguish between them. They know when an approval catches a real issue and when it merely sends the same information to another inbox. They also know which unofficial repair keeps a supposedly automated process running.
I explored this movement of scarce work in When Output Becomes Abundant. The practical next step for almost every organization I have observed is to make all of this more visible. Measure time spent working, waiting, reviewing, and repairing. Follow a sample of jobs until the intended outcome occurs. Include the cases that fail, get abandoned, or return later with a problem.
Otherwise, an impressive productivity gain in one department can become an unmeasured burden in another. All too often, I have seen cases where someone wants to automate a task to benefit some local maximum while negatively impacting the enterprise as a whlie. In such situations, the costs and delays shift and potentially multiply rather than disappear, creating friction that can undermine the overall efficiency of the organization.
This is where scenario planning becomes useful. An organization needs several plausible accounts of how its work could change with the introduction of AI, with observations that would help distinguish between them.
Suppose model capability improves slowly, while lower costs and better tooling make familiar tasks economical to automate. That future favors careful workflow engineering. We would look for stable quality at lower total cost and sustained reductions in human effort.
Suppose coordinated systems begin completing longer, more difficult assignments reliably. That future could justify changes to roles and delegated responsibility. We would need evidence from complete assignments, including exceptions, recovery, and performance on work that differs from the examples used to tune the system.
Suppose generation accelerates while verification, integration, or physical delivery remains constrained. That future calls for investment in the limiting stages. Rising queues, older unfinished work, repeated corrections, and delayed customer outcomes would be signals to investigate.
These possibilities can coexist. Software maintenance, procurement, and field engineering may develop at different rates inside the same company. An enterprise-wide label for AI maturity would conceal those differences.
Each scenario should connect to a decision. What would persuade us to expand delegation? What would cause us to invest in testing capacity? What result would tell us to stop adding agents and simplify the workflow? Which commitment would be expensive to reverse if our assumptions proved wrong?
Set thresholds before the pilot. A team should agree on acceptable quality, cost, intervention, and recovery requirements while it can still discuss them without defending a rollout. The thresholds will differ by class of work and consequence.
In How Much Work Can Your AI Safely Own?, I distinguished capability, evidence, and authority. Demonstrated ability contributes to a decision about responsibility. It does not make that decision for us.
So how would you begin; I would begin with one important class of work and its current baseline. Record the time, cost, quality, and human effort required today. Then compare the proposed AI arrangement on representative cases, including difficult exceptions.
Keep the model version, instructions, tools, permissions, and relevant data changes with the results. If several of those change together, be careful about attributing the improvement to one of them. Preserve failed attempts and escalations alongside successes, with access and retention appropriate to the information involved. If you do not track that information, or you fail to account for this, you will not have a reliable basis for evaluating progress.
This also means you should track the consequences after acceptance too. A support case that reopens, a code change that requires repair, or a document that creates confusion downstream is a type of failure that belongs in the evaluation. The reporting boundary should follow the processes already established lines of responsibility starting with the customers request all the way to the customer getting their need answered. In other words, the full and complete Value Stream should be considered when evaluating the impact of AI on work.
This evidence collection needs an owner and a place in ordinary operations. The development team that’s building the solution needs to have access to it. The operational teams that are supporting the technology need to have access to it. Every relevant team should review it often enough to act before a growing queue or recurring error becomes normal. Material changes to the model, workflow, or workload should trigger another look at the assumptions behind the plan.
The purpose is to make changing course less expensive. We should be able to discover that one agent works better than five, that a stronger model earns its higher price, or that an apparently successful automation moved too much work onto someone else. Each finding should have a route into a decision.
The part of Hannah’s Lego project I keep returning to is her willingness to change how she approached it. The instructions were available from the beginning. Progress also involved recognizing when help would be useful and learning how to use the experience around her.
There are limits to the comparison. A Lego set comes with a known design. An enterprise adopting AI is still discovering some of what it can build. That makes it even more important to examine the work as it takes shape and to preserve what we learn.
Hannah had saved for a cat she wanted to build. My help mattered because it supported that purpose and her growing ability to carry it forward. When we decide how to organize AI at work, I want us to keep an equally clear view of the people we are helping, the outcome they need, and the evidence that we are getting closer to it.
", "url": "https://tedt.org/When-AI-Moves-Faster-Than-the-Organization/", "image": "/img/2026-09/Lego-cat-story.webp", "tags": ["enterprise AI","agentic AI","collective intelligence","operating model","scenario planning","AI governance","value stream","evidence-based evaluation"], "date_published": "2026-09-26T00:00:00-07:00", "date_modified": "2026-09-26T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/When-AI-Evaluators-Also-Sell-AI-Adoption/", "title": "When AI Evaluators Also Sell AI Adoption", "summary": "When an AI evaluator also sells adoption, buyers need evidence that inconvenient findings can reach decision-makers and change a deployment decision.", "content_text": "When I bought my house, one of the inspectors sold us on a roof inspection.That seemed like a sensible thing for a new homeowner to buy. We needed help understanding the house. An inspection was supposed to give us information we could use to make a decision.The inspection turned out to be an on-ramp into a sales system. The inspection team also had roofing solutions to sell, and the company’s intention was to move us toward buying those solutions and adding the costs of those solutions to the homeloan. Helping a new homeowner understand the roof had become secondary to creating another sale.The problem was the purpose the inspection served.That experience is a useful place to begin with AI evaluation. When someone hands you an assessment, whose decision is it designed to improve? What happens when the evidence points toward buying less, delaying the work or walking away?Those questions became more concrete on Sept. 18, when Anthropic announced “Partnering with Accenture on embedded evaluation.” What’s going to happen under this partnership is that Accenture’s specialist AI business, will lead the work, with Anthropic funding it directly. The stated scope includes evaluating models, examining alignment and testing safeguards.When Evaluation Meets an Existing Sales RelationshipThere is an existing commercial relationship behind that announcement. In December 2025, Accenture and Anthropic announced a partnership that included a dedicated Claude practice and joint offerings to help enterprises adopt AI. That earlier announcement is useful context: the organizations already had a business relationship oriented toward expanding deployment.Now there is an evaluation relationship too.That combination deserves examination. It does not establish that Accenture or Faculty has compromised an assessment, suppressed a finding or failed to act independently. My roof inspection supplies a question to investigate. It supplies no evidence about their conduct.The question is whether an evaluator can deliver a commercially inconvenient judgment about Anthropic or Accenture, and whether the people who are going to pay for that that judgment will receive it reliably.Independence Has to Survive Ordinary PressuresIn “Dev, Test, and Prod Still Matter: What Gets Deployed Has Changed,” I argued that independent evaluation requires attention to the machinery around the test: access, isolation, evidence retention and responsibility when something goes wrong.There is another layer around that machinery. People choose the questions, negotiate the scope, assign the staff, renew the contract and decide where the report goes.A technically excellent test can sit inside a relationship that makes some questions difficult to ask. An evaluator might have access to the model while lacking a protected route for escalating a disagreement. A customer might hear that an evaluation occurred without learning which important questions it left unanswered.These are possibilities to investigate, not findings about the new partnership. They explain why the commercial arrangement belongs in the assessment.In “Winning the Intelligence Inversion,” I described independent risk governance as part of the operating model for AI. This development brings that principle into a purchasing decision. Independence has to survive the ordinary pressures of an organization: budgets, reporting lines, important accounts and the desire to keep work moving.Nobody has to be dishonest for those pressures to matter.Suppose an evaluation raises a problem that would delay a major rollout. The immediate issue is technical. The consequences reach account teams, delivery commitments, customer expectations and revenue. A credible arrangement should already explain who decides what happens next. Leaving that decision until everyone is under pressure makes the evaluator’s job harder.The Case for Embedded EvaluationBut there is a strong argument for the arrangement Anthropic has announced.People who help organizations deploy AI may understand failures that a distant reviewer misses. They may recognize the difference between a convincing demonstration and a workflow that breaks when permissions change, records conflict or a user does something unexpected. Embedded access could also reveal decisions and practices that cannot be reconstructed from a finished model.Distance can protect judgment. It can also limit understanding. Another aspect to consider in addition to distance is the longevity of the evaluation. Just because a model passes an evaluation at one point in time does not guarantee it will continue to meet the same standards as it evolves. Long-term monitoring and repeated assessments are necessary to maintain confidence in the model’s behavior.Will Knight’s Sept. 18 WIRED article, “Here’s How an AI Slowdown Could Actually Be Enforced,” captures this disagreement. Geoffrey Irving argues that inspections can help constrain development; Raymond Douglas emphasizes unresolved questions about effective controls. The reporting offers reasons to investigate inspection methods carefully, alongside a credible case for using them.Payment alone cannot settle these question either. Evaluation takes skilled people, time and access. Someone must fund it. Moving the invoice to a nonprofit, a pooled fund or a government body changes the incentives without eliminating the need to examine them.Anthropic acknowledges that access, reporting, and funding standards remain unsettled. It describes a nonexclusive arrangement, plans for additional evaluators and discussions about other funding approaches. Those are relevant commitments. Their practical value will depend on how they operate.What Protects an Uncomfortable Finding?There are also proposed protections that deserve a fair hearing.In his September essay, “We Must Pace the Frontier,” Dario Amodei proposes allowing embedded reviewers to publish key findings without Anthropic’s editorial control. He describes limited redactions for specified sensitive information and says reviewers should be able to disclose when a redaction materially affects their conclusions.Those proposals address a central concern in this article. They would give an evaluator a way to make an uncomfortable conclusion visible.They should also be described accurately. A proposed protection is different from a verified provision in a particular signed agreement. The public partnership announcement does not spell out appointment and removal protections, commercial separation or the complete publication arrangement. That leaves questions for reporting. It does not prove those safeguards are absent.Disclosure itself needs judgment.A report could contain customer information, exploitable vulnerabilities or other material that should not be published openly. Demanding unrestricted publication would create problems of its own. Buyers should instead ask who can receive detailed findings through protected channels, how redactions are reviewed, how disagreements are escalated and whether a public summary can explain the assessment’s limits.The useful distinction is between protecting sensitive information and preventing an adverse conclusion from reaching someone who can act on it.A Model Assessment Is Not a Deployment DecisionThere is a further limit to the roof-inspection comparison. In my case, we were the customers buying the inspection. An enterprise relying on a model developer’s evaluation may have no direct contractual relationship with the evaluator. It may receive a summary intended for a different audience and a different decision.That makes scope especially important.An assessment of a model developer’s safeguards can be valuable while leaving many questions about a customer’s deployment unanswered. Which records does the application retrieve? Whose permissions does it use? What can it change? Can an affected person challenge the result? Does the system behave acceptably in the languages and operating conditions where the organization uses it?A model-level assessment cannot answer those questions simply by existing.The Electronic Frontier Foundation supplies a useful challenge to a narrow view of safety. Its Sept. 18 “Statement on California Governor’s Executive Order on AI” supports third-party investigations while calling attention to present harms involving employment, benefits, surveillance and pricing. EFF is an advocacy organization; its statement identifies priorities rather than proving the effectiveness of a particular inspection method.The distinction matters for an enterprise reader. A bank, an employer and a public agency can use the same model and create quite different consequences. Their customers and employees encounter the whole service, including the policies and decisions wrapped around the model.In “How Much Work Can Your AI Safely Own?” I separated capability, evidence and authority. An external assessment can contribute evidence. The organization still has to decide what work to authorize and remain responsible for that decision. Anthropic likewise states that embedded evaluation does not transfer its responsibility for model safety.Five Questions for Enterprise BuyersSo what should an enterprise buyer actually request?Start with the decision the evidence is supposed to support. Expanding an internal drafting assistant and allowing an agent to change customer records require different cases. Then ask for enough information to understand five things: Scope: What system, version, configuration and use cases were examined? Which relevant questions were excluded? Access: What could the evaluator inspect, and what limitations affected its conclusions? Commercial safeguards: Who appoints, pays and can remove the evaluator? How are related implementation interests disclosed and managed? Reporting: Who receives adverse findings, who can redact them and where can an unresolved disagreement go? Follow-through: Who owns remediation, what evidence demonstrates improvement and what changes trigger another assessment?These are proposed purchasing questions, not claims about a universal standard already in place. Their depth should match the consequence of the work.Useful Scrutiny Has to Be AffordableThere is a cost argument here that should not be waved away. A medium-sized organization cannot necessarily commission a bespoke investigation of every supplier. An elaborate assurance requirement could favor established providers and leave smaller buyers dependent on reports they have little ability to question. EFF’s call to make investigations accessible to smaller developers points toward the same concern.Reusable evidence, common reporting formats and proportionate reviews could help. A shared assessment should make its boundaries easy to understand so each customer can concentrate on the remaining questions in its own deployment. Repeating the same expensive inspection everywhere is not the only way to obtain useful scrutiny.Nor is waiting for perfect independence a satisfactory plan. It could leave organizations relying on less evidence while institutions and methods develop. The practical task is to improve the arrangement, expose its limitations and keep testing whether it works.Keep the Option to Say NoThe evidence could ultimately support the Anthropic–Accenture approach. Protected disclosure, meaningful separation of commercial interests, sufficient access and a record of consequential findings would make a stronger case for embedded evaluation. Deployment expertise could prove to be one of its advantages.That possibility belongs in the argument. The purpose of scrutiny is to learn whether an arrangement deserves trust.The roof inspection failed us because the process served the next roofing sale more than it served a new homeowner. We needed help making a decision about our house. The inspection team had built a way to sell us more “solutions.”An enterprise needs an assessment that leaves several choices open: proceed, narrow the deployment, repair the problem, obtain more evidence or decline the purchase.A useful evaluator must be able to support any of those choices. The people making the decision must be able to see why.Before accepting the next AI assessment, ask what happens if its most useful conclusion would reduce the next sale.That was the question inside our roof inspection. It belongs inside the AI contract too.", "content_html": "When I bought my house, one of the inspectors sold us on a roof inspection.
That seemed like a sensible thing for a new homeowner to buy. We needed help understanding the house. An inspection was supposed to give us information we could use to make a decision.
The inspection turned out to be an on-ramp into a sales system. The inspection team also had roofing solutions to sell, and the company’s intention was to move us toward buying those solutions and adding the costs of those solutions to the homeloan. Helping a new homeowner understand the roof had become secondary to creating another sale.
The problem was the purpose the inspection served.
That experience is a useful place to begin with AI evaluation. When someone hands you an assessment, whose decision is it designed to improve? What happens when the evidence points toward buying less, delaying the work or walking away?
Those questions became more concrete on Sept. 18, when Anthropic announced “Partnering with Accenture on embedded evaluation.” What’s going to happen under this partnership is that Accenture’s specialist AI business, will lead the work, with Anthropic funding it directly. The stated scope includes evaluating models, examining alignment and testing safeguards.
There is an existing commercial relationship behind that announcement. In December 2025, Accenture and Anthropic announced a partnership that included a dedicated Claude practice and joint offerings to help enterprises adopt AI. That earlier announcement is useful context: the organizations already had a business relationship oriented toward expanding deployment.
Now there is an evaluation relationship too.
That combination deserves examination. It does not establish that Accenture or Faculty has compromised an assessment, suppressed a finding or failed to act independently. My roof inspection supplies a question to investigate. It supplies no evidence about their conduct.
The question is whether an evaluator can deliver a commercially inconvenient judgment about Anthropic or Accenture, and whether the people who are going to pay for that that judgment will receive it reliably.
In “Dev, Test, and Prod Still Matter: What Gets Deployed Has Changed,” I argued that independent evaluation requires attention to the machinery around the test: access, isolation, evidence retention and responsibility when something goes wrong.
There is another layer around that machinery. People choose the questions, negotiate the scope, assign the staff, renew the contract and decide where the report goes.
A technically excellent test can sit inside a relationship that makes some questions difficult to ask. An evaluator might have access to the model while lacking a protected route for escalating a disagreement. A customer might hear that an evaluation occurred without learning which important questions it left unanswered.
These are possibilities to investigate, not findings about the new partnership. They explain why the commercial arrangement belongs in the assessment.
In “Winning the Intelligence Inversion,” I described independent risk governance as part of the operating model for AI. This development brings that principle into a purchasing decision. Independence has to survive the ordinary pressures of an organization: budgets, reporting lines, important accounts and the desire to keep work moving.
Nobody has to be dishonest for those pressures to matter.
Suppose an evaluation raises a problem that would delay a major rollout. The immediate issue is technical. The consequences reach account teams, delivery commitments, customer expectations and revenue. A credible arrangement should already explain who decides what happens next. Leaving that decision until everyone is under pressure makes the evaluator’s job harder.
But there is a strong argument for the arrangement Anthropic has announced.
People who help organizations deploy AI may understand failures that a distant reviewer misses. They may recognize the difference between a convincing demonstration and a workflow that breaks when permissions change, records conflict or a user does something unexpected. Embedded access could also reveal decisions and practices that cannot be reconstructed from a finished model.
Distance can protect judgment. It can also limit understanding. Another aspect to consider in addition to distance is the longevity of the evaluation. Just because a model passes an evaluation at one point in time does not guarantee it will continue to meet the same standards as it evolves. Long-term monitoring and repeated assessments are necessary to maintain confidence in the model’s behavior.
Will Knight’s Sept. 18 WIRED article, “Here’s How an AI Slowdown Could Actually Be Enforced,” captures this disagreement. Geoffrey Irving argues that inspections can help constrain development; Raymond Douglas emphasizes unresolved questions about effective controls. The reporting offers reasons to investigate inspection methods carefully, alongside a credible case for using them.
Payment alone cannot settle these question either. Evaluation takes skilled people, time and access. Someone must fund it. Moving the invoice to a nonprofit, a pooled fund or a government body changes the incentives without eliminating the need to examine them.
Anthropic acknowledges that access, reporting, and funding standards remain unsettled. It describes a nonexclusive arrangement, plans for additional evaluators and discussions about other funding approaches. Those are relevant commitments. Their practical value will depend on how they operate.
There are also proposed protections that deserve a fair hearing.
In his September essay, “We Must Pace the Frontier,” Dario Amodei proposes allowing embedded reviewers to publish key findings without Anthropic’s editorial control. He describes limited redactions for specified sensitive information and says reviewers should be able to disclose when a redaction materially affects their conclusions.
Those proposals address a central concern in this article. They would give an evaluator a way to make an uncomfortable conclusion visible.
They should also be described accurately. A proposed protection is different from a verified provision in a particular signed agreement. The public partnership announcement does not spell out appointment and removal protections, commercial separation or the complete publication arrangement. That leaves questions for reporting. It does not prove those safeguards are absent.
Disclosure itself needs judgment.
A report could contain customer information, exploitable vulnerabilities or other material that should not be published openly. Demanding unrestricted publication would create problems of its own. Buyers should instead ask who can receive detailed findings through protected channels, how redactions are reviewed, how disagreements are escalated and whether a public summary can explain the assessment’s limits.
The useful distinction is between protecting sensitive information and preventing an adverse conclusion from reaching someone who can act on it.
There is a further limit to the roof-inspection comparison. In my case, we were the customers buying the inspection. An enterprise relying on a model developer’s evaluation may have no direct contractual relationship with the evaluator. It may receive a summary intended for a different audience and a different decision.
That makes scope especially important.
An assessment of a model developer’s safeguards can be valuable while leaving many questions about a customer’s deployment unanswered. Which records does the application retrieve? Whose permissions does it use? What can it change? Can an affected person challenge the result? Does the system behave acceptably in the languages and operating conditions where the organization uses it?
A model-level assessment cannot answer those questions simply by existing.
The Electronic Frontier Foundation supplies a useful challenge to a narrow view of safety. Its Sept. 18 “Statement on California Governor’s Executive Order on AI” supports third-party investigations while calling attention to present harms involving employment, benefits, surveillance and pricing. EFF is an advocacy organization; its statement identifies priorities rather than proving the effectiveness of a particular inspection method.
The distinction matters for an enterprise reader. A bank, an employer and a public agency can use the same model and create quite different consequences. Their customers and employees encounter the whole service, including the policies and decisions wrapped around the model.
In “How Much Work Can Your AI Safely Own?” I separated capability, evidence and authority. An external assessment can contribute evidence. The organization still has to decide what work to authorize and remain responsible for that decision. Anthropic likewise states that embedded evaluation does not transfer its responsibility for model safety.
So what should an enterprise buyer actually request?
Start with the decision the evidence is supposed to support. Expanding an internal drafting assistant and allowing an agent to change customer records require different cases. Then ask for enough information to understand five things:
These are proposed purchasing questions, not claims about a universal standard already in place. Their depth should match the consequence of the work.
There is a cost argument here that should not be waved away. A medium-sized organization cannot necessarily commission a bespoke investigation of every supplier. An elaborate assurance requirement could favor established providers and leave smaller buyers dependent on reports they have little ability to question. EFF’s call to make investigations accessible to smaller developers points toward the same concern.
Reusable evidence, common reporting formats and proportionate reviews could help. A shared assessment should make its boundaries easy to understand so each customer can concentrate on the remaining questions in its own deployment. Repeating the same expensive inspection everywhere is not the only way to obtain useful scrutiny.
Nor is waiting for perfect independence a satisfactory plan. It could leave organizations relying on less evidence while institutions and methods develop. The practical task is to improve the arrangement, expose its limitations and keep testing whether it works.
The evidence could ultimately support the Anthropic–Accenture approach. Protected disclosure, meaningful separation of commercial interests, sufficient access and a record of consequential findings would make a stronger case for embedded evaluation. Deployment expertise could prove to be one of its advantages.
That possibility belongs in the argument. The purpose of scrutiny is to learn whether an arrangement deserves trust.
The roof inspection failed us because the process served the next roofing sale more than it served a new homeowner. We needed help making a decision about our house. The inspection team had built a way to sell us more “solutions.”
An enterprise needs an assessment that leaves several choices open: proceed, narrow the deployment, repair the problem, obtain more evidence or decline the purchase.
A useful evaluator must be able to support any of those choices. The people making the decision must be able to see why.
Before accepting the next AI assessment, ask what happens if its most useful conclusion would reduce the next sale.
That was the question inside our roof inspection. It belongs inside the AI contract too.
", "url": "https://tedt.org/When-AI-Evaluators-Also-Sell-AI-Adoption/", "image": "/img/2026-09/AI-Evaluators-Selling-Adoption.webp", "tags": ["AI evaluation","AI governance","AI safety","embedded evaluation","evaluator independence","enterprise procurement","Anthropic","Accenture"], "date_published": "2026-09-19T00:00:00-07:00", "date_modified": "2026-09-19T00:00:00-07:00","author":{"name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/Beyond-the-Mirror/", "title": "Beyond the Mirror: Principles for Work in the Age of AI", "summary": "AI can take on more information work, but it cannot decide what work should mean for people. This manifesto argues for shared purpose, a living commons, coordinated autonomy, and shared gains as the foundations of communal work.", "content_text": "In 2001, I sat in Bob’s Big Boy in Burbank, talking with Erik Davis of WIRED about plans to camp out with Tolkien Online fans before a movie premiere. I told him, “People want to participate in the universe they love.” He recorded the conversation.Take that same sentance and instead of talking about movies, books, and fandom, frame it into a discussion about the future of work. Put that sentence in a meeting with colleagues and it becomes a surprising idea.Participation means having something to contribute. It means being able to affect what happens. It means that someone would notice the difference between your presence and your absence. An organization can give a person an account, a title, a queue of tasks, and a full calendar, but it doesn’t always give them meaningful work. It doesn’t give them a “universe” that they love.But that was in 2001. Today things are very different. Today we are building artificially intelligent machines which take on work and be members of that team. They can handle a larger share of the tasks in the queue.So, what happens to the person?I think that question is going to require us to reconsider something much older than artificial intelligence. It asks what we believe work is for, what holds a community together, and how much of our current organization exists to compensate for limitations our technology is learning to remove.The question becomes urgent when we confuse a person’s place in a process with their place among other people.In the video, Why Bullsh✲t Jobs are (Finally) Dying, the narrator approaches this from the economics of corporate work. They describe layers of people once needed to move information through large organizations. The argument is that digital communication weakened that need, while cheap capital and organizational incentives helped preserve the layers. And now, AI adds another source of pressure on routine reports and summaries.The useful question the video leaves me with is whether we still need every agreement, process, and approach we inherited. Its broader claims about useless jobs deserve more scrutiny. A company continuing to operate after layoffs does not establish that everything those people did was unnecessary. Maintenance, accumulated knowledge, and relationships can take time to reveal their absence.But there is something worth following here. We can remove the technical reason for a particular kind of work and continue organizing people around it for years.In my 2009 writing on collaboration, I described what happens when knowledge cannot be preserved, found, or checked against its purpose. People compensate. They schedule another meeting, ask someone who knows someone, or carry information from one tool into the next. The informal network becomes the way the formal organization gets anything done.Those people are often holding the organization together. Their effort is real. So is the possibility that we have made them responsible for a problem we should have solved in a different way.We gave the office electronic forms(files) and electronic filing cabinets(folders). We also kept a great many people busy moving the contents between them. AI makes it harder to avoid asking why.I think AI may be the final general-purpose layer of Information Age technology.That is a large claim, so let me say what I mean by it. We have learned to store information, calculate with it, search it, and move it around the world. We are now learning to delegate more of the work of interpreting it and acting on it. We can describe an intended result and give a system some responsibility for finding a way to produce it.That ability is incomplete and uneven. A system that handles a well-defined task can still fail when the context changes. But the direction suggests a culminating capability: information becomes something we can ask machines to use toward an outcome, with less of the method supplied by a person at every step.An earlier version of this argument appears in my white paper on moving beyond Industrial Age utility practices. The practical concern there was preserving context as information moves through an organization. AI brings another possibility into view. The information can increasingly carry work with it.If that is the direction, much of what comes next may look like operational improvement: better memory, stronger reasoning, lower cost, more reliable execution, clearer interfaces, and wider access. The word “operational” can make this sound smaller than it is. A capability becoming dependable enough for ordinary use can change far more lives than its first impressive demonstration.I am making a claim about the direction of information technology. Scientific discovery remains open. There may be another transformation beyond the one I can see. This argument does not require us to declare invention finished.It requires us to notice that we already have enough new capability to question the organization of work. An organizing structure, which was put in place to manage the limitations of the Industrial Revolution, may no longer be optimal. Waiting for a more perfect model is a way of postponing decisions about ourselves.Consider the phrase: agents swarm; humans click.It captures a difference in how work gets arranged. An agent system can divide a question into parts, send those parts to other agents, and bring their results together. Meanwhile, a person opens a ticket, copies a number into a spreadsheet, asks for access, attaches a document, and waits for the next person to do much the same thing.That is a description of a working environment, not a limit on human nature. People have always organized around shared problems. Scientific communities, volunteer projects, and open-source software show how much can happen when contributions can accumulate across many participants. We are quite capable of finding one another and building something together. Yet much of enterprise work places that ability inside a succession of private inboxes and departmental queues.In Agents Don’t Click, I argued that software changes when agents become its operators. The visible interface becomes less central to routine execution, while authoritative records, permissions, and evidence become more consequential. The next question is what happens to the organization built around those interfaces.Swarming does not make coordination free. Anthropic’s account of building a system with multiple research agents describes a lead agent assigning parallel investigations and bringing the results together. It also describes duplicated effort, coordination costs, and difficulties when tasks depend heavily on one another. Useful cooperation requires the work to be defined and the results to be checked.There is a lesson for us in that. We must organize around the actual dependencies of the work. Those dependencies determine the order in which tasks should be performed. In order to do that effectively, we need to understand the relationships between tasks. Best practices here include mapping out task dependencies, identifying critical paths, and continuously reworking the team structure and workflow until you have all those dependencies built into the team and the flow of work.The distinction can be difficult to see from inside a familiar job. A handoff may contain an essential judgment, an obsolete copying step, or both. You find out by involving the person who does it and examining what changes because of their contribution.We see this early in IT because code, requests, documentation, tests, and changes already have digital forms. Some outcomes can be checked quickly, and some mistakes can be reversed. That makes parts of our work accessible to agents before work that requires a physical presence or carries consequences that are harder to evaluate.The same pressure can spread as other kinds of work become accessible. Cheaper execution changes which arrangements are economical. Organizations redesign roles and boundaries in response. The choices they make about ownership, responsibility, and the gains determine what that redesign means for people.That is a causal path toward much of the economic disruption people fear. It is also a place where human decisions still matter.The dread makes sense. A person may have spent twenty years becoming the one who can assemble the answer. Their authority, income, friendships, and sense of usefulness may all be connected to that role. Telling them that a machine can assemble the answer in minutes raises questions that a productivity chart cannot answer.An exponential curve makes those questions harder. We can extend a line on a graph beyond our ability to imagine the institutions that would exist at its far end. We put today’s job descriptions, income arrangements, and professional identities underneath tomorrow’s capability and watch them stop fitting.Then we look for ourselves in that future.This is the mirror I think we are standing in front of. It reflects the arrangements we recognize and the things we are afraid of losing. It gives us a picture of our present under pressure. It cannot show us every way people might learn to belong and contribute after those arrangements change.A prediction can correctly identify a failure in the current system without exhausting the possibilities beyond it.That does not make every warning mistaken. Losing a livelihood is a real loss. Concentrating power in the hands of those who own the machines is a real political choice. Technical failures and misuse need their own answers. No metaphor makes those problems disappear.But the end of a familiar arrangement does not tell us that human possibility ends there.Reaching through the mirror means taking responsibility for arrangements we have not built yet. It means asking who gets a say, who gets access, what contribution earns recognition, and how people can remain secure while their work changes. Hope has to take a form someone can live inside.That is why I keep coming back to community.Years ago, in Defending the Commons, I used a garden to distinguish a community from the resource it cares for and the value that resource produces. The people, their shared ground, and its fruit are different things. A useful organization has to care about all three.In knowledge work, that shared ground includes what we know, how we arrived at it, what we have tried, what failed, and which promises we have made. It includes the experience of the person who notices an exception before it becomes an incident. It includes the conditions that let a newcomer ask a question without first earning entry to an insider network.We can call this a living commons: knowledge that people can find, question, improve, and use within legitimate boundaries. Someone must maintain it. Someone must notice when a once-correct answer becomes wrong. Its value depends on continued participation.AI can make that commons easier to search and more useful in doing the work. It can also generate so much plausible material that finding what deserves trust becomes harder. A pile of generated documents is not a community’s memory until people have a way to establish what belongs there and why.This is the distinction I explored in When Output Becomes Abundant. Production can accelerate while judgment and agreement become more demanding. Removing the need to relay a status update does not remove the need to hear an objection, make a commitment, or take responsibility for someone affected by a decision.That human work deserves time. It also deserves a better setting than an endless procession of meetings whose purpose nobody can quite explain.The original Agile Manifesto challenged rigid approaches to software development by emphasizing people, collaboration, and adaptation. Its principles included self-organization, trust, and a sustainable pace. There is a great deal there worth carrying forward.I want to extend that approach to the community of work itself, beginning with capabilities that now exist. Knowledge can persist beyond a conversation. Contributions can arrive across time and distance. Agents can take on bounded work. The results of one effort can become the starting point for the next.If we began there, what would we choose to value?Principles for Work in the Age of AIWe begin with knowledge that can be shared, work that can proceed in parallel, and learning that can outlast any one participant. We organize people and agents around purposes the community can understand and help shape.We value: Shared purpose over inherited boundaries. A living commons over isolated experts. Coordinated and Collaborative autonomy over serial handoffs. Shared capability and gains over isolated productivity.Roles, expertise, handoffs, and individual achievement remain useful. We judge them by how well they serve these principles.Shared purpose means the people involved can explain who the work serves and what would make it worthwhile. They can also question it. If participation amounts to helping execute a decision nobody is allowed to examine, we have given the old arrangement a more appealing name. The people who do the work and the people who live with its consequences need a voice in defining success.A living commons means expertise becomes something others can build upon. A useful decision leaves its reasoning behind. A corrected error improves the shared method. The person who documents a difficult exception receives credit for making everyone more capable. Privacy and confidentiality still apply, but access should not depend on knowing the right person to have a drink with after work.Coordinated autonomy means giving people and agents room to act within a clear purpose and appropriate limits. Independent work can proceed together. Dependencies stay visible. Someone has authority to accept the result, and someone can interrupt the work when it goes wrong. Accountability is a responsibility we name and support, not something we hope will emerge from the group.Shared capability and shared gains mean asking what happens to the benefit. A team that teaches a system how its work really operates has contributed more than training data. Its members have supplied judgment, history, and ways of recognizing trouble. They should help decide how the recovered capacity is used, whether that means better service, time to learn, new responsibilities, or a more sustainable working day. When a role does disappear, that conversation must include paid time to retrain, support between roles, and how the affected people share in the benefit.This is where the manifesto becomes more demanding than a call for efficiency.If AI makes an organization more productive, leaders need to decide how the collective will benefit. That could mean better pay, greater job security, time to learn, or more control over their work. Employees should help shape those decisions. Promising that AI will eventually make their work more valuable is not enough; people need meaningful influence now.AI agents may work around the clock, but people need reasonable hours and time away. Faster machines should not create an expectation that employees constantly review results, answer questions, or take on more work. Organizations should define what a completed job looks like and recognize its completion. Finishing sooner with AI should count as success, rather than automatically creating another obligation for more human effort.You can test these commitments without reorganizing an entire company.Imagine a recurring customer problem that needs a policy answer, an operational correction, and a clear explanation. In the familiar arrangement, three teams prepare three versions of the response. Each waits for information held by another. Giving everyone an AI assistant might make the documents arrive faster while leaving the customer in the same queue.Now organize the work around one shared outcome with, the relevant evidence, and the unresolved questions visible to the people authorized to work on it. Let agents investigate independent parts of the problem. Bring people together where the work requires judgment or agreement. Preserve the resolution and its reasoning so the next customer who is stuck in this problem can benefit.The most revealing part may be what happens to the employee who used to carry the case between those teams. That person may know why the handoffs fail, which information is usually missing, and which exceptions cannot be treated as routine. Give them a role in changing the process. Their knowledge can become a contribution to the whole process instead of a skill the process keeps privately consuming.Then examine the result. Did the customer receive a better outcome? Did the team spend less time recovering the context of the customer’s predicament? Did errors and rework decline? Could a new colleague understand what needed to be done? Did the participants gain useful time and influence over their work?If all we can demonstrate is that the system produced more text faster, we have more work to do.I have argued before that AI adoption requires a change in the operating model. The communal question goes further. It asks what the new model owes to the people whose contributions make it possible. It asks whether a more capable institution can also become a place where people have a more meaningful part to play.There is no guarantee that we will make that choice. Technology gives us possibilities, and institutions decide which ones become way of everyday life. We can use cheaper information work to preserve the same private authority with fewer people around it. We can also use it to widen access to knowledge, bring more experience into decisions, to spend more time making hard decisions, and make participation less dependent on where someone happens to sit in the building or in the organization.The machinery alone cannot decide which future is worthwhile.I come back to that conversation at Bob’s Big Boy, where we were talking about our plans for bringing Tolkien fans together.There is a particular pleasure in finding people who care about a story you love. You can ask the question nobody else around you understands. Someone remembers a passage you missed. Someone else sees a character differently. What began as reading becomes a conversation, and the conversation gives people something to build together.That is the possibility I want us to carry into the next age of work. Machines can help us find the information, prepare the work, and make more things possible. We still have to make room for one another in deciding what those possibilities are for. A person should be able to bring what they know, learn from someone else, and have a hand in what happens next.The future beyond the mirror is difficult to picture. We can begin with something familiar: people gathering around a shared purpose, each with something to contribute. We can build the next part together.Fellowship seems like a good word for that.So I invite you, come and join the conversation; pull up a chair!", "content_html": "In 2001, I sat in Bob’s Big Boy in Burbank, talking with Erik Davis of WIRED about plans to camp out with Tolkien Online fans before a movie premiere. I told him, “People want to participate in the universe they love.” He recorded the conversation.
Take that same sentance and instead of talking about movies, books, and fandom, frame it into a discussion about the future of work. Put that sentence in a meeting with colleagues and it becomes a surprising idea.
Participation means having something to contribute. It means being able to affect what happens. It means that someone would notice the difference between your presence and your absence. An organization can give a person an account, a title, a queue of tasks, and a full calendar, but it doesn’t always give them meaningful work. It doesn’t give them a “universe” that they love.
But that was in 2001. Today things are very different. Today we are building artificially intelligent machines which take on work and be members of that team. They can handle a larger share of the tasks in the queue.
So, what happens to the person?
I think that question is going to require us to reconsider something much older than artificial intelligence. It asks what we believe work is for, what holds a community together, and how much of our current organization exists to compensate for limitations our technology is learning to remove.
The question becomes urgent when we confuse a person’s place in a process with their place among other people.
In the video, Why Bullsh✲t Jobs are (Finally) Dying, the narrator approaches this from the economics of corporate work. They describe layers of people once needed to move information through large organizations. The argument is that digital communication weakened that need, while cheap capital and organizational incentives helped preserve the layers. And now, AI adds another source of pressure on routine reports and summaries.
The useful question the video leaves me with is whether we still need every agreement, process, and approach we inherited. Its broader claims about useless jobs deserve more scrutiny. A company continuing to operate after layoffs does not establish that everything those people did was unnecessary. Maintenance, accumulated knowledge, and relationships can take time to reveal their absence.
But there is something worth following here. We can remove the technical reason for a particular kind of work and continue organizing people around it for years.
In my 2009 writing on collaboration, I described what happens when knowledge cannot be preserved, found, or checked against its purpose. People compensate. They schedule another meeting, ask someone who knows someone, or carry information from one tool into the next. The informal network becomes the way the formal organization gets anything done.
Those people are often holding the organization together. Their effort is real. So is the possibility that we have made them responsible for a problem we should have solved in a different way.
We gave the office electronic forms(files) and electronic filing cabinets(folders). We also kept a great many people busy moving the contents between them. AI makes it harder to avoid asking why.
I think AI may be the final general-purpose layer of Information Age technology.
That is a large claim, so let me say what I mean by it. We have learned to store information, calculate with it, search it, and move it around the world. We are now learning to delegate more of the work of interpreting it and acting on it. We can describe an intended result and give a system some responsibility for finding a way to produce it.
That ability is incomplete and uneven. A system that handles a well-defined task can still fail when the context changes. But the direction suggests a culminating capability: information becomes something we can ask machines to use toward an outcome, with less of the method supplied by a person at every step.
An earlier version of this argument appears in my white paper on moving beyond Industrial Age utility practices. The practical concern there was preserving context as information moves through an organization. AI brings another possibility into view. The information can increasingly carry work with it.
If that is the direction, much of what comes next may look like operational improvement: better memory, stronger reasoning, lower cost, more reliable execution, clearer interfaces, and wider access. The word “operational” can make this sound smaller than it is. A capability becoming dependable enough for ordinary use can change far more lives than its first impressive demonstration.
I am making a claim about the direction of information technology. Scientific discovery remains open. There may be another transformation beyond the one I can see. This argument does not require us to declare invention finished.
It requires us to notice that we already have enough new capability to question the organization of work. An organizing structure, which was put in place to manage the limitations of the Industrial Revolution, may no longer be optimal. Waiting for a more perfect model is a way of postponing decisions about ourselves.
Consider the phrase: agents swarm; humans click.
It captures a difference in how work gets arranged. An agent system can divide a question into parts, send those parts to other agents, and bring their results together. Meanwhile, a person opens a ticket, copies a number into a spreadsheet, asks for access, attaches a document, and waits for the next person to do much the same thing.
That is a description of a working environment, not a limit on human nature. People have always organized around shared problems. Scientific communities, volunteer projects, and open-source software show how much can happen when contributions can accumulate across many participants. We are quite capable of finding one another and building something together. Yet much of enterprise work places that ability inside a succession of private inboxes and departmental queues.
In Agents Don’t Click, I argued that software changes when agents become its operators. The visible interface becomes less central to routine execution, while authoritative records, permissions, and evidence become more consequential. The next question is what happens to the organization built around those interfaces.
Swarming does not make coordination free. Anthropic’s account of building a system with multiple research agents describes a lead agent assigning parallel investigations and bringing the results together. It also describes duplicated effort, coordination costs, and difficulties when tasks depend heavily on one another. Useful cooperation requires the work to be defined and the results to be checked.
There is a lesson for us in that. We must organize around the actual dependencies of the work. Those dependencies determine the order in which tasks should be performed. In order to do that effectively, we need to understand the relationships between tasks. Best practices here include mapping out task dependencies, identifying critical paths, and continuously reworking the team structure and workflow until you have all those dependencies built into the team and the flow of work.
The distinction can be difficult to see from inside a familiar job. A handoff may contain an essential judgment, an obsolete copying step, or both. You find out by involving the person who does it and examining what changes because of their contribution.
We see this early in IT because code, requests, documentation, tests, and changes already have digital forms. Some outcomes can be checked quickly, and some mistakes can be reversed. That makes parts of our work accessible to agents before work that requires a physical presence or carries consequences that are harder to evaluate.
The same pressure can spread as other kinds of work become accessible. Cheaper execution changes which arrangements are economical. Organizations redesign roles and boundaries in response. The choices they make about ownership, responsibility, and the gains determine what that redesign means for people.
That is a causal path toward much of the economic disruption people fear. It is also a place where human decisions still matter.
The dread makes sense. A person may have spent twenty years becoming the one who can assemble the answer. Their authority, income, friendships, and sense of usefulness may all be connected to that role. Telling them that a machine can assemble the answer in minutes raises questions that a productivity chart cannot answer.
An exponential curve makes those questions harder. We can extend a line on a graph beyond our ability to imagine the institutions that would exist at its far end. We put today’s job descriptions, income arrangements, and professional identities underneath tomorrow’s capability and watch them stop fitting.
Then we look for ourselves in that future.
This is the mirror I think we are standing in front of. It reflects the arrangements we recognize and the things we are afraid of losing. It gives us a picture of our present under pressure. It cannot show us every way people might learn to belong and contribute after those arrangements change.
A prediction can correctly identify a failure in the current system without exhausting the possibilities beyond it.
That does not make every warning mistaken. Losing a livelihood is a real loss. Concentrating power in the hands of those who own the machines is a real political choice. Technical failures and misuse need their own answers. No metaphor makes those problems disappear.
But the end of a familiar arrangement does not tell us that human possibility ends there.
Reaching through the mirror means taking responsibility for arrangements we have not built yet. It means asking who gets a say, who gets access, what contribution earns recognition, and how people can remain secure while their work changes. Hope has to take a form someone can live inside.
That is why I keep coming back to community.
Years ago, in Defending the Commons, I used a garden to distinguish a community from the resource it cares for and the value that resource produces. The people, their shared ground, and its fruit are different things. A useful organization has to care about all three.
In knowledge work, that shared ground includes what we know, how we arrived at it, what we have tried, what failed, and which promises we have made. It includes the experience of the person who notices an exception before it becomes an incident. It includes the conditions that let a newcomer ask a question without first earning entry to an insider network.
We can call this a living commons: knowledge that people can find, question, improve, and use within legitimate boundaries. Someone must maintain it. Someone must notice when a once-correct answer becomes wrong. Its value depends on continued participation.
AI can make that commons easier to search and more useful in doing the work. It can also generate so much plausible material that finding what deserves trust becomes harder. A pile of generated documents is not a community’s memory until people have a way to establish what belongs there and why.
This is the distinction I explored in When Output Becomes Abundant. Production can accelerate while judgment and agreement become more demanding. Removing the need to relay a status update does not remove the need to hear an objection, make a commitment, or take responsibility for someone affected by a decision.
That human work deserves time. It also deserves a better setting than an endless procession of meetings whose purpose nobody can quite explain.
The original Agile Manifesto challenged rigid approaches to software development by emphasizing people, collaboration, and adaptation. Its principles included self-organization, trust, and a sustainable pace. There is a great deal there worth carrying forward.
I want to extend that approach to the community of work itself, beginning with capabilities that now exist. Knowledge can persist beyond a conversation. Contributions can arrive across time and distance. Agents can take on bounded work. The results of one effort can become the starting point for the next.
If we began there, what would we choose to value?
We begin with knowledge that can be shared, work that can proceed in parallel, and learning that can outlast any one participant. We organize people and agents around purposes the community can understand and help shape.
We value:
Roles, expertise, handoffs, and individual achievement remain useful. We judge them by how well they serve these principles.
Shared purpose means the people involved can explain who the work serves and what would make it worthwhile. They can also question it. If participation amounts to helping execute a decision nobody is allowed to examine, we have given the old arrangement a more appealing name. The people who do the work and the people who live with its consequences need a voice in defining success.
A living commons means expertise becomes something others can build upon. A useful decision leaves its reasoning behind. A corrected error improves the shared method. The person who documents a difficult exception receives credit for making everyone more capable. Privacy and confidentiality still apply, but access should not depend on knowing the right person to have a drink with after work.
Coordinated autonomy means giving people and agents room to act within a clear purpose and appropriate limits. Independent work can proceed together. Dependencies stay visible. Someone has authority to accept the result, and someone can interrupt the work when it goes wrong. Accountability is a responsibility we name and support, not something we hope will emerge from the group.
Shared capability and shared gains mean asking what happens to the benefit. A team that teaches a system how its work really operates has contributed more than training data. Its members have supplied judgment, history, and ways of recognizing trouble. They should help decide how the recovered capacity is used, whether that means better service, time to learn, new responsibilities, or a more sustainable working day. When a role does disappear, that conversation must include paid time to retrain, support between roles, and how the affected people share in the benefit.
This is where the manifesto becomes more demanding than a call for efficiency.
If AI makes an organization more productive, leaders need to decide how the collective will benefit. That could mean better pay, greater job security, time to learn, or more control over their work. Employees should help shape those decisions. Promising that AI will eventually make their work more valuable is not enough; people need meaningful influence now.
AI agents may work around the clock, but people need reasonable hours and time away. Faster machines should not create an expectation that employees constantly review results, answer questions, or take on more work. Organizations should define what a completed job looks like and recognize its completion. Finishing sooner with AI should count as success, rather than automatically creating another obligation for more human effort.
You can test these commitments without reorganizing an entire company.
Imagine a recurring customer problem that needs a policy answer, an operational correction, and a clear explanation. In the familiar arrangement, three teams prepare three versions of the response. Each waits for information held by another. Giving everyone an AI assistant might make the documents arrive faster while leaving the customer in the same queue.
Now organize the work around one shared outcome with, the relevant evidence, and the unresolved questions visible to the people authorized to work on it. Let agents investigate independent parts of the problem. Bring people together where the work requires judgment or agreement. Preserve the resolution and its reasoning so the next customer who is stuck in this problem can benefit.
The most revealing part may be what happens to the employee who used to carry the case between those teams. That person may know why the handoffs fail, which information is usually missing, and which exceptions cannot be treated as routine. Give them a role in changing the process. Their knowledge can become a contribution to the whole process instead of a skill the process keeps privately consuming.
Then examine the result. Did the customer receive a better outcome? Did the team spend less time recovering the context of the customer’s predicament? Did errors and rework decline? Could a new colleague understand what needed to be done? Did the participants gain useful time and influence over their work?
If all we can demonstrate is that the system produced more text faster, we have more work to do.
I have argued before that AI adoption requires a change in the operating model. The communal question goes further. It asks what the new model owes to the people whose contributions make it possible. It asks whether a more capable institution can also become a place where people have a more meaningful part to play.
There is no guarantee that we will make that choice. Technology gives us possibilities, and institutions decide which ones become way of everyday life. We can use cheaper information work to preserve the same private authority with fewer people around it. We can also use it to widen access to knowledge, bring more experience into decisions, to spend more time making hard decisions, and make participation less dependent on where someone happens to sit in the building or in the organization.
The machinery alone cannot decide which future is worthwhile.
I come back to that conversation at Bob’s Big Boy, where we were talking about our plans for bringing Tolkien fans together.
There is a particular pleasure in finding people who care about a story you love. You can ask the question nobody else around you understands. Someone remembers a passage you missed. Someone else sees a character differently. What began as reading becomes a conversation, and the conversation gives people something to build together.
That is the possibility I want us to carry into the next age of work. Machines can help us find the information, prepare the work, and make more things possible. We still have to make room for one another in deciding what those possibilities are for. A person should be able to bring what they know, learn from someone else, and have a hand in what happens next.
The future beyond the mirror is difficult to picture. We can begin with something familiar: people gathering around a shared purpose, each with something to contribute. We can build the next part together.
Fellowship seems like a good word for that.
So I invite you, come and join the conversation; pull up a chair!
", "url": "https://tedt.org/Beyond-the-Mirror/", "image": "/img/2026-09/Thru-the-Mirror-The-Future-of-work.webp", "tags": ["future of work","human-ai collaboration","knowledge commons","organizational design","coordinated autonomy","shared gains","community"], "date_published": "2026-09-11T00:00:00-07:00", "date_modified": "2026-09-11T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/slides/openai-hugging-face-wiki/", "title": "OpenAI, Hugging Face & Wikis: Recent Developments", "summary": "\n", "content_text": "", "content_html": "", "url": "https://tedt.org/slides/openai-hugging-face-wiki/", "image": "/slides/decks/openai-hugging-face-wiki/slide-preview.png", "date_published": "2026-09-10T00:00:00-07:00", "date_modified": "2026-09-10T00:00:00-07:00","author":{"name":"Ted Tschopp","url":"https://tedt.org/profile/","uri":"https://tedt.org/profile/","avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","givenname":"Ted","familyname":"Tschopp","othernames":"Þeodor Tʃopp | टेड चप | Фёдор Чоп | تد شُپ | Թեդ Չոպպ | Ted Çop | டெட் சாப் | טעד טשאָפּ | Τεντ Τσοπ | 테드 촙 | 特德·察普 | テッド・チョッパ | ტედ ჩოპი | เท็ด ชอพ | ເທດ ຊອບ | ടെഡ് ചോപ്പ് | টেড চপ | ཏེཌ་ ཅོཔ། | ቴድ ቾፕ | ᏖᏗ ᏦᏇ | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | 𐌀𐌄𐌃 𐌕𐌔𐌂𐌏𐌐𐌐 | Ⱅⰵⰴ ⱌⱁⱂⱂ | ܬܝܕ ܟܘܦ | ᠲᠡᠳᠡᠳ ᠴᠣᠫ | ᑌᑎ ᒍᐳᐱ | ꕚꔳ ꗍꖛ | ߕߋߘ ߞߐߔߔ | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐎚𐎄𐎆 𐎚𐎌𐎒𐎒 | 𐎄𐎓𐎆 𐎚𐎔𐎒𐎒 | 𐤕𐤄𐤃 𐤕𐤔𐤐𐤐 | 𐤕𐤃𐤄 𐤕𐤔𐤏𐤐 | 𐎚𐎄𐎆 𐎚𐎘𐎔𐎔 | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | 𓏏𓂧𓂝 𓏏𓊃𓍿𓊪 | ⲧⲉⲇ ⲧϣⲟⲡⲡ | 𐌕𐌄𐌃 𐌕𐌔𐌎𐌐𐌐 | 𐤈𐤃𐤄 𐤈𐤔𐤐𐤐 | 𐌕𐌄𐌃 𐌕𐌔𐌏𐌐𐌐 | 𐌕𐌄𐌃 𐌕𐌔𐌐𐌐 | 𐎄𐎕𐎆 𐎚𐎑𐎔𐎔 | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐀳𐀂𐀅 𐀳𐀴𐀞 | 𐱃𐰀𐰓 𐱃𐰴𐰯 | 𑀢𑁂𑀤𑁆 𑀘𑁄𑀧𑁆 | 𐨟𐨂𐨡 𐨖𐨎𐨿 | 𐦚𐦱𐦟 𐦚𐦷𐦣 | 𐭓𐭐𐭃 𐭓𐭱𐭕𐭕 | 𐭲𐭩𐭣 𐭲𐭱𐭯𐭯 | ᚈᚓᚇ ᚈᚄᚉᚑᚚᚚ | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | تيد تشوب | ટેડ ચોક્પ | ਟੇਡ ਚੋਪ | ಟೆಡ್ ಚೊಪ್ | ටෙඩ් චොප් | တက် ချော့ပ် | តេដ ឆប | ꦠꦺꦢ꧀ ꦕꦺꦴꦥ꧀ | ᬢᭂᬤ᭄ ᬘᭀᬧ᭄ | ᜆᜒᜇ᜔ ᜆ᜔ᜐᜓᜉ᜔ | ᏖᏗ ᏣᏊ | ꄊꄮ ꍏꀠ | ଟେଡ୍ ଚୋପ୍ | ⵜⴻⴷ ⵛⵓⵒ | 𐐓𐐯𐐼 𐐟𐐙𐐱𐐹 | 𐑑𐑧𐑛 𐑗𐑪𐑐 | 𐘳𐘂𐘅 𐘳𐘴𐘞 | 𐠔𐠁𐠊 𐠔𐠷𐠡 | 𐊗𐊁𐊅 𐊗𐊐𐊓 | 𐊴𐊭𐊺 𐊴𐋄𐊸 | 𐢞𐢉𐢅 𐢞𐢝𐢘 | ࠕࠄࠃ ࠕࠔࠐࠐ | 𐫤𐫏𐫝 𐫤𐫘𐫖 | ꡈꡦ ꡐꡡꡌ | ꯇꯦꯗ ꯆꯣꯄ | ꨓꨯꨕ ꨌꨱꨚ | ᨲᩮᨯ᩠ ᨩᩮᩫ᩠ | ꪔꫀꪒ ꪊꪮꪚ | ᯖᯩᯑ᯲ ᯙᯬᯇ᯲ | ꥆꥍꤴ ꥓ꥏꥒ | ᨈᨙᨉᨛ ᨌᨚᨄᨛ | ᮒᮨᮓ᮪ ᮎᮧᮕ᮪ | ᜦᜒᜇ᜴ ᜰᜳᜉ᜴ | ᝆᝒᝇ ᝌᝓᝉ | ꠔꠦꠖ ꠌꠥꠙ | 𑂞𑂵𑂠 𑂒𑂷𑂣 | 𑆠𑆼𑆢𑇀 𑆖𑆾𑆥𑇀 | 𑚔𑚵𑚖 𑚏𑚴𑚞 | 𑲌𑲏 𑱰𑱱 | 𑊢𑋐𑊦 𑊓𑋒 | 𑈋𑈸𑈍𑈴 𑈑𑈺𑈞𑈴 | 𑅐𑅬𑅒 𑅘𑅛 | 𑘝𑘿𑘟 𑘓𑘽𑘨 | 𑜔𑜦𑜕 𑜒𑜩𑜞 | 𑣕𑣈𑣙 𑣌𑣏𑣗 | 𞠔𞠀𞠙 𞠌𞠁𞠖 | 𑫎𑫟𑫒 𑫏𑫝𑫐 | 𐓰𐒰𐓈 𐓍𐒷𐓄 | 𞤚𞤫𞤣 𞤷𞤮𞥄 | 𖫐𖫪𖫓 𖫗𖫩𖫞 | 𛰙𛱎𛰣 𛲄𛱖𛱐 | ","biography":["I'm **Ted Tschopp**, a Senior Enterprise Architect based in Los Angeles, working at the intersection of **enterprise architecture, artificial intelligence, software strategy, and digital automation**.","At **Southern California Edison**, I help shape the architecture strategy for AI, software, and enterprise products that support one of the nation’s largest electric utilities. My work sits where **strategy meets execution**: platforms, guardrails, operating models, governance, risk, developer experience, and the practical realities of making ambitious technology useful, resilient, and sustainable inside a large organization.","I've spent **25+ years at SCE** helping teams navigate complex technology change. The part of enterprise architecture I care about most is not the diagram. It is the design discipline that makes systems usable, governable, sustainable, and welcoming for the people who depend on them and the teams who build them.","Before joining Edison, I owned a business featured in *Wired Magazine*, founded one of the largest J.R.R. Tolkien community websites, and worked in automotive market research. That mix of technology, storytelling, community-building, and analysis still shapes how I think about systems today.","I love working in technology because it lets me watch the future arrive in real time. Some of the things I have worked on were science fiction when I was in school. Now they are platform problems, governance problems, people problems, and architecture problems — which is where the interesting work begins.","Unless otherwise stated, everything here reflects my own views."],"email":"ted@tschopp.org","phonenumber":null,"keybaseio_username":"tedtschopp","twitter_username":"TedTschopp","twitter":"TedTschopp","github_username":"TedTschopp","linkedin_username":"tedtschopp","facebook_username":"ted.tschopp","google_username":"TedTschopp","youtube_username":"TedTschopp","pinterest_username":"TedTschopp","reddit_username":"tedtschopp","instagram_username":"tedtschopp","quora_username":"Ted-Tschopp","indiewebcamp_username":"Www.tedt.org","mastodon_username":"TedT@twit.social","mastodon_user_id":109286944787814808,"threads_username":"TedTschopp@threads.net","same_as":["https://www.linkedin.com/in/tedtschopp","https://github.com/TedTschopp","https://twit.social/@TedT","https://bsky.app/profile/tedt.org","https://twitter.com/TedTschopp","https://www.youtube.com/channel/UC4Q8pXroTVyXrIxg2u82pwg"],"knows_about":["Enterprise architecture","Enterprise artificial intelligence","AI governance","Software and platform strategy","Digital automation","Technology-enabled organizational change","Digital communities and storytelling","Swiss folklore","Tabletop role-playing game design"],"works_for":{"name":"Southern California Edison","url":"https://www.sce.com/"}}}, { "id": "https://tedt.org/Energy-and-Water-Usage-for-Models/", "title": "How Much Energy and Water Does AI Use?", "summary": "AI uses electricity and water, but the impact depends on the task, the model, and the facility. Familiar comparisons help explain the scale.", "content_text": "I was asked how much electricity and water AI uses, and what that means. These are shared resources, and questions about their use deserve clear answers. The numbers vary, but familiar comparisons can help put them in context.For a short text answer, the electricity use can be quite small. A 2026 study estimated about 0.3 watt-hours, roughly enough to run a 10-watt LED lightbulb for two minutes. A longer reasoning response in the same study was estimated to use about 4 watt-hours, equivalent to keeping that bulb on for 24 minutes. These estimates describe particular text-based tasks and computing systems; individual requests can use more or less. Research studyAt the shorter-response estimate, asking 100 questions every day for a year would use around 11 kilowatt-hours—about what a 1,500-watt space heater uses in seven hours. A small amount per answer can still add up to substantial demand when millions of people use these services.Training an AI model is a larger, separate undertaking. Training GPT-3, released in 2020, was estimated to require 1.3 million kilowatt-hours: roughly a year’s electricity purchases for 120 average U.S. homes, using the government’s 2022 household benchmark. Developing and updating a model can involve several training stages and experiments, but answering an ordinary question does not restart that process. Training estimate, household benchmarkWater use is harder to describe with one number. Google estimated about five drops of cooling water for its typical Gemini text response in May 2025. Mistral reported 45 milliliters—about three tablespoons—for a roughly 300-word response, using a broader calculation that includes impacts beyond cooling, such as manufacturing equipment. These figures describe different systems and count different things, so they cannot establish which service uses less water overall. Google study, Mistral disclosureTraining also has a water footprint. One research scenario estimated 5.4 million liters for GPT-3’s training when cooling and electricity generation were included. That is just over two Olympic-size swimming pools, assuming 2.5 million liters per pool. Another way of thinking about this at SCE is that this is the amount of water it would take to fill the pools of water that cooled the spent fuel at SONGS Unit 2 4x when it was operational. Another SONGS compairson is that this was the amount of salt water SONGS Unit 2 and 3 processed in roughly 51 seconds to generate power. That 5.4 million liters of water is a research estimate, rather than a disclosed measurement of water consumed during the actual training run. Water studyThe water is not destroyed. Evaporated water enters the atmosphere and eventually returns as precipitation, but it may return somewhere else or much later. A community experiencing drought still needs water in its own reservoirs and groundwater supplies today. That local availability is an important part of the environmental impact. USGS explanationThere are practical ways to reduce demand. Some cooling systems circulate the same water repeatedly, much like a car’s radiator. Microsoft reports that more than 90 percent of its Fairwater facility’s capacity uses a system with no evaporation losses. That illustrates what newer facilities can achieve. Microsoft’s descriptionSome escaping water can also be recovered. In 2021, MIT described demonstrations at its power facilities of equipment that collects water droplets from cooling-tower plumes and returns them for reuse. MIT demonstrationCooling water can also carry useful heat from the computers. Recovering that heat can warm buildings and reduce their need for other heating sources. In a 2024 report, Meta said its Odense data center supplied recovered heat through a local heating network to about 7,000 households. This makes further use of the energy consumed by computers; it does not recover all that energy or turn it back into electricity. Meta’s facility reportPacific Gas and Electric Company and developer Westbank announced plans in April 2025 for a San Jose development with three data centers and up to 4,000 homes. The project would reuse data-center heat through a network serving surrounding buildings. PG&E announcementFor text, “tokens” are the small pieces of words and punctuation an AI processes. Electricity and water use can be expressed per million tokens, but those figures depend on the model, the task, and the facilities serving it. They are useful accounting measures when those conditions are specified.", "content_html": "I was asked how much electricity and water AI uses, and what that means. These are shared resources, and questions about their use deserve clear answers. The numbers vary, but familiar comparisons can help put them in context.
For a short text answer, the electricity use can be quite small. A 2026 study estimated about 0.3 watt-hours, roughly enough to run a 10-watt LED lightbulb for two minutes. A longer reasoning response in the same study was estimated to use about 4 watt-hours, equivalent to keeping that bulb on for 24 minutes. These estimates describe particular text-based tasks and computing systems; individual requests can use more or less. Research study
At the shorter-response estimate, asking 100 questions every day for a year would use around 11 kilowatt-hours—about what a 1,500-watt space heater uses in seven hours. A small amount per answer can still add up to substantial demand when millions of people use these services.
Training an AI model is a larger, separate undertaking. Training GPT-3, released in 2020, was estimated to require 1.3 million kilowatt-hours: roughly a year’s electricity purchases for 120 average U.S. homes, using the government’s 2022 household benchmark. Developing and updating a model can involve several training stages and experiments, but answering an ordinary question does not restart that process. Training estimate, household benchmark
Water use is harder to describe with one number. Google estimated about five drops of cooling water for its typical Gemini text response in May 2025. Mistral reported 45 milliliters—about three tablespoons—for a roughly 300-word response, using a broader calculation that includes impacts beyond cooling, such as manufacturing equipment. These figures describe different systems and count different things, so they cannot establish which service uses less water overall. Google study, Mistral disclosure
Training also has a water footprint. One research scenario estimated 5.4 million liters for GPT-3’s training when cooling and electricity generation were included. That is just over two Olympic-size swimming pools, assuming 2.5 million liters per pool. Another way of thinking about this at SCE is that this is the amount of water it would take to fill the pools of water that cooled the spent fuel at SONGS Unit 2 4x when it was operational. Another SONGS compairson is that this was the amount of salt water SONGS Unit 2 and 3 processed in roughly 51 seconds to generate power. That 5.4 million liters of water is a research estimate, rather than a disclosed measurement of water consumed during the actual training run. Water study
The water is not destroyed. Evaporated water enters the atmosphere and eventually returns as precipitation, but it may return somewhere else or much later. A community experiencing drought still needs water in its own reservoirs and groundwater supplies today. That local availability is an important part of the environmental impact. USGS explanation
There are practical ways to reduce demand. Some cooling systems circulate the same water repeatedly, much like a car’s radiator. Microsoft reports that more than 90 percent of its Fairwater facility’s capacity uses a system with no evaporation losses. That illustrates what newer facilities can achieve. Microsoft’s description
Some escaping water can also be recovered. In 2021, MIT described demonstrations at its power facilities of equipment that collects water droplets from cooling-tower plumes and returns them for reuse. MIT demonstration
Cooling water can also carry useful heat from the computers. Recovering that heat can warm buildings and reduce their need for other heating sources. In a 2024 report, Meta said its Odense data center supplied recovered heat through a local heating network to about 7,000 households. This makes further use of the energy consumed by computers; it does not recover all that energy or turn it back into electricity. Meta’s facility report
Pacific Gas and Electric Company and developer Westbank announced plans in April 2025 for a San Jose development with three data centers and up to 4,000 homes. The project would reuse data-center heat through a network serving surrounding buildings. PG&E announcement
For text, “tokens” are the small pieces of words and punctuation an AI processes. Electricity and water use can be expressed per million tokens, but those figures depend on the model, the task, and the facilities serving it. They are useful accounting measures when those conditions are specified.
", "url": "https://tedt.org/Energy-and-Water-Usage-for-Models/", "image": "/img/2026-09/Energy-and-Water-Usage-for-Models.webp", "tags": ["AI energy use","AI water use","model training","AI inference","data centers","cooling","heat recovery","sustainability"], "date_published": "2026-09-06T00:00:00-07:00", "date_modified": "2026-09-06T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/The-Same-Model-Different-Rules/", "title": "The Same Model, Different Rules", "summary": "AI procurement must define not only which model is approved, but also its access rules, data custody, interruption response, and exit arrangements.", "content_text": "The Same Model, Different RulesA Broken iPhone and a Slowly Charging BlackBerryIn 2007, I dropped my iPhone at lunch. The glass shattered.At the Apple Store, I was told the repair would cost $250. I asked for a loaner. They didn’t have one. I asked to have the repaired phone shipped to my home. One employee said they couldn’t do that. Another corrected him: they could. A refurbished replacement wasn’t an option either.So I was back on my BlackBerry, which was charging slowly, while I waited for an iPhone expected back in two or three business days.The broken glass was easy to see. The other dependencies became visible one question at a time. What would the store repair? What could it replace? Who knew the shipping rules? What could I use while the phone was gone?The answers determined how I would get through the interruption.An enterprise choosing an AI service faces a version of that same problem. The technology may be impressive. But the work also depends on arrangements around it: who can use it, who can change the conditions, and what remains available when the preferred option disappears.Those arrangements deserve attention before something breaks.AI procurement now includes the conditions under which work can start, continue, and stop.On June 9, Anthropic released Claude Fable 5 and its restricted-access counterpart, Mythos 5. Three days later, access to both was suspended.In its account of the interruption, Anthropic said newly imposed export controls required restrictions based on nationality. Unable to verify nationality reliably in real time, it suspended access for everyone. Fable access was restored on July 1. Anthropic’s account.A team evaluating the model could have tested its answers, measured its speed, and calculated its cost. Those tests would have helped determine whether it could do useful work. They would not have established whether the team could keep using it when the conditions of access changed.That is the purchasing question the September announcements bring into sharper focus.An enterprise needs to approve a service configuration: the model, the route to it, the people permitted to use it, the data arrangements, and the response when any of those conditions changes. A model name alone cannot describe that purchase.The Differences Are Already Reaching BuyersAnthropic describes Fable 5.1 and Mythos 5.1 as the same underlying model with different safeguards. Fable is generally available; Mythos is offered through trusted-access arrangements supporting sensitive cybersecurity and life-sciences work. Access remains program-dependent. Anthropic’s September announcement.Google describes Gemini 3.8 Flash and Flash Cyber as sharing foundational intelligence, with different safeguards and deployment arrangements. Flash Cyber is restricted to trusted defenders through Fairwind. Google’s wording does not establish identical model weights, so the two companies’ claims should not be treated as interchangeable. Google’s announcement.Restricted access is not new. What these releases make increasingly visible is how much of the product sits around the intelligence.The differences also extend beyond the model companies’ announcements.Harvey’s Sept. 1 notice makes Fable 5.1 an opt-in offering. It warns that the model’s processing practices may differ from commitments in existing customer agreements, describes a time-bound zero-retention arrangement for eligible customers, and says processing occurs in the United States. Those statements describe Harvey’s published offering; they should not be generalized to every distribution channel. Harvey’s implementation notice.Cursor documents a different set of operating decisions. Enterprise customers need explicit approval to enable Fable 5.1. Cursor’s own Privacy Mode does not eliminate Anthropic’s separate retention requirements. Requests that trigger safeguards can automatically fall back to Opus. Cursor’s documentation.These are commercially interested providers describing their implementations, not independent studies of customer outcomes. They nevertheless establish something useful: choosing the model does not settle the terms under which an employee encounters it.The route matters. So does the agreement attached to that route.Write Down the Service You Are ApprovingIn “Model Portability Is Not AI Portability,” I argued that moving a model does not automatically move the complete working system. The newer question is what happens when parts of that system change while the model name stays the same.Anthropic’s versioning documentation provides a concrete example. A model ID pins the model’s weights and configuration, but surrounding infrastructure—including routing, safety classifiers, and sampling logic—can change. The documentation says those changes can affect observable behavior. Model IDs and versioning.A fixed model version is useful. It is not a frozen service.The enterprise catalog therefore needs to record more than “approved model.” It needs to describe the approved use of that model and the evidence supporting the approval.Consider a hypothetical internal source-code review service. Its purpose is to inspect approved repositories and propose repairs. The following is a proposed approval record, not a claim that a particular product already satisfies every requirement. Boundary Proposed Configuration Owner and Evidence Model and routing Fable 5.1 through the company gateway to the Claude API; no unapproved fallback The platform owner records the exact model ID, interface, routing settings, and test results. Supplier-controlled changes are tracked separately. Eligible users and entities One corporate entity’s internal security team; no assumed access for affiliates or contractors Procurement confirms applicable access rights. The identity team enforces membership. Unconfirmed coverage blocks access. Permitted actions Read isolated copies of two approved repositories and draft patches; no merging or production deployment The application owner enforces tool permissions and tests attempted actions outside that scope. Data handling Only approved source code, with processing, storage, review locations, and retention explicitly accepted Privacy and security owners retain the applicable terms and verified data-flow description. Unknown locations or retention conditions block approval. Monitoring and evidence Company-held records of requests, actions, approvals, and unfinished work, limited to necessary information Security identifies authorized reviewers and tests whether required evidence remains retrievable after supplier access is lost. Interruption and recovery Pause affected jobs; use a separately approved alternative or manual review The service owner names the person authorized to resume work and records a tested recovery procedure. Each row needs a status: documented, contractually confirmed where necessary, or not yet tested. A public description of a feature is not evidence that the enterprise has enabled it correctly.There are also two different owners to record. One can change the condition. The other decides whether the enterprise can continue operating after that change.The supplier may change a classifier. Your architecture board cannot prevent that merely by approving a design. It can decide what evidence is needed afterward and whether the affected workflow must pause.That distinction turns an inventory into an operating record.Keep Control of the ActionsProvider permission and enterprise authority still answer different questions.A supplier may permit vulnerability analysis. That does not authorize an agent to inspect every system reachable from your network. An employee may be allowed to read a repository without being allowed to deploy a repair.The earlier capability-versus-authority argument remains the foundation. The purchasing decision now needs to establish which controls the enterprise can enforce independently of the supplier’s judgment.For consequential workflows, those controls should include user identity, permitted tools and targets, approval before consequential changes, records of completed actions, and a way to stop further execution. Their effectiveness should not depend on the model agreeing that a request is inappropriate.Google’s Fairwind requirements illustrate the division. Google controls program admission, while participants must implement user authentication, phishing-resistant multifactor authentication, applicable access controls, and tracking of employee access and use. Access is limited to specified internal security teams. Fairwind’s governance requirements.This does not mean every enterprise should rebuild the provider’s safeguards.A managed service may be sufficient when it can demonstrate the required controls and the customer can administer and audit them. An enterprise-controlled harness becomes necessary where the workflow requires permissions, approvals, evidence, or recovery that the managed service cannot reliably provide.“Controlled” does not have to mean “built from scratch.” It means the organization can establish and enforce the required boundary. If neither the purchased service nor an integration can do that, the consequential action should remain outside the automation.Data Custody Is Another Operating ResponsibilityAnthropic’s planned Enterprise Frontier Safeguards would allow monitoring data to reside in customer-controlled cloud infrastructure, with options for customer-managed keys and customer review of flagged activity. Rollout is planned in phases later this fall. The storage, key-management, and review options are separately configurable; the announcement should not be read as proof that every customer already has them. Enterprise Frontier Safeguards.Its interim zero-retention arrangement also has limits. Anthropic describes it as temporary and restricted to eligible uses. Real-time safeguards and enforcement continue to apply, and the company says it may modify or withdraw the arrangement. Covered Models guidance.Moving records into the customer’s environment changes custody. It does not remove the need to monitor activity, investigate problems, or establish who can suspend service.Someone must receive the alert. Someone must have permission to examine the evidence. Someone must distinguish misuse from legitimate work that was incorrectly flagged.For a multinational organization, the approval record should separately identify the contracting entity, eligible users, inference locations, stored-data locations, and locations from which people may review the data. An approved storage region does not answer all those questions.Harvey’s processing notice supplies one concrete reason to ask. It does not establish what every organization in Europe, the United Kingdom, or Asia-Pacific may lawfully or contractually do. Those decisions require the exact service configuration and applicable agreement, not a general claim of global availability.Purchase the Change and Exit ArrangementsThe contract discussion should describe events, not merely desirable qualities.Anthropic’s public commercial terms, for example, allow suspension in specified circumstances and describe reasonable efforts to provide written notice and restore access after a curable cause is resolved. That is different from a guaranteed advance-warning period or a fixed recovery time. Customer-specific agreements may differ. Public commercial terms, Section I.Procurement, legal, security, and the service owner should resolve four practical matters: Changes and versions: What is pinned, what can change around it, what notice is available, and what testing is required before affected work continues? Scope and location: Which entities, employees, contractors, purposes, and processing arrangements are covered? Does an approval survive a change in any of them? Evidence and review: What information can the customer obtain during an incident, who reviews disputed flags, and what remains accessible if the account is suspended? Revocation and exit: What can trigger loss of eligibility, how can a decision be challenged, and what export, transition assistance, charges, and time limits apply?These are matters to confirm or negotiate, not assurances that suppliers necessarily offer.The purchasing decision must also survive an unwelcome answer. If the provider cannot guarantee advance notice, a critical workflow needs a tested interruption response. If the evidence needed to reconstruct a transaction cannot be obtained, that workflow may need different architecture.A contract cannot prevent every interruption. It can make the responsibilities clearer before people are trying to recover under pressure.Rehearse Losing AccessNow take the hypothetical code-review service and interrupt it.The supplier suspends the organization’s access while several reviews are underway. Some draft patches have been saved. Other jobs are waiting. This is a planning scenario, not a reported customer incident.The platform should stop dispatching affected work and preserve the records it is authorized to retain. The service owner should establish which jobs completed, which produced partial work, and which never started.Paused does not mean rolled back.Next, determine the scope and reason for the restriction. A service interruption, suspected credential misuse, and a prohibition on the requested activity require different responses. An alternative model is appropriate only when the work remains permitted and the replacement’s access rights, data handling, quality, and controls have been approved. Changing accounts to evade a restriction is not recovery.If no approved alternative exists, route the work to manual review or hold it. The owner should know how much work that alternative can absorb and when delays become unacceptable.This is where the harness around the model earns its cost. It preserves the organization’s ability to understand and manage unfinished work, even when the supplier is unavailable.The rehearsal should also produce a cost estimate.Suppose a switch requires 80 engineering hours and 40 review hours at an assumed blended rate of $150 an hour. That is $18,000 before additional licenses, parallel operation, service charges, or delayed work. These are illustrative assumptions, not measured customer costs.Use your own drill to replace them.Record the effort required to reconstruct work, validate the replacement, obtain approvals, and clear the backlog. Compare that expense with the cost of maintaining a ready alternative. Some workflows will justify the investment. Others will be adequately served by a documented manual procedure.Token prices alone cannot make that decision.Keep the Claim ProportionateThe public evidence supports a narrower conclusion than a sweeping transformation of every enterprise purchase.Specialized access may remain concentrated in sensitive domains. Providers may be better equipped than individual customers to operate sophisticated safeguards. A routine drafting workflow may need little beyond existing access controls and a human fallback.There is also an evidence boundary. Harvey and Cursor document real service arrangements, but their notices are not independent evaluations of enterprise outcomes. Public documentation does not establish the full regional eligibility of restricted programs, negotiated customer commitments, or measured switching costs. Those parts of the original reporting brief remain open.The practical conclusion does not require pretending otherwise.Before placing consequential work behind a model endpoint, describe the complete service, identify who can change its conditions, and test how the work will be recovered. Scale that preparation to the consequence of interruption.We don’t need to return to June. This week OpenAI launched a new set of models, including those that are restricted to people working in the cyber security space. If you intend to apply for access to these systems, you need to understand the eligibility requirements and prepare the necessary documentation, the question was no longer simply how well the model could perform. It also needs to include how you will handle interruptions, maintain continuity, and ensure that critical work can proceed even if access is temporarily unavailable.The work still needs somewhere to go.A useful AI purchasing decision gives it that place: a permitted route, a recoverable state, and a person who knows what happens next.The Practical LessonI broke that iPhone, and for a while lost access to my brand new phone. A shattered screen and a supplier suspending model access are different failures.But both lead to a practical question: what can you do while the thing you depend on is unavailable?I had asked for a loaner. What I actually had was my old phone, aslowly charging BlackBerry. Returning to it was inconvenient, but it gave me something to use while I waited.For an enterprise, the equivalent deserves more preparation. The alternative needs the right permissions, access to the necessary work, and someone authorized to decide when it is safe to continue. Its limitations need to be understood before people are depending on it.Choose the capable model. Test what it can accomplish. Then give the arrangements around it the same attention.Before handing over important work, know what your BlackBerry is.And make sure it is charged.", "content_html": "In 2007, I dropped my iPhone at lunch. The glass shattered.
At the Apple Store, I was told the repair would cost $250. I asked for a loaner. They didn’t have one. I asked to have the repaired phone shipped to my home. One employee said they couldn’t do that. Another corrected him: they could. A refurbished replacement wasn’t an option either.
So I was back on my BlackBerry, which was charging slowly, while I waited for an iPhone expected back in two or three business days.
The broken glass was easy to see. The other dependencies became visible one question at a time. What would the store repair? What could it replace? Who knew the shipping rules? What could I use while the phone was gone?
The answers determined how I would get through the interruption.
An enterprise choosing an AI service faces a version of that same problem. The technology may be impressive. But the work also depends on arrangements around it: who can use it, who can change the conditions, and what remains available when the preferred option disappears.
Those arrangements deserve attention before something breaks.
AI procurement now includes the conditions under which work can start, continue, and stop.
On June 9, Anthropic released Claude Fable 5 and its restricted-access counterpart, Mythos 5. Three days later, access to both was suspended.
In its account of the interruption, Anthropic said newly imposed export controls required restrictions based on nationality. Unable to verify nationality reliably in real time, it suspended access for everyone. Fable access was restored on July 1. Anthropic’s account.
A team evaluating the model could have tested its answers, measured its speed, and calculated its cost. Those tests would have helped determine whether it could do useful work. They would not have established whether the team could keep using it when the conditions of access changed.
That is the purchasing question the September announcements bring into sharper focus.
An enterprise needs to approve a service configuration: the model, the route to it, the people permitted to use it, the data arrangements, and the response when any of those conditions changes. A model name alone cannot describe that purchase.
Anthropic describes Fable 5.1 and Mythos 5.1 as the same underlying model with different safeguards. Fable is generally available; Mythos is offered through trusted-access arrangements supporting sensitive cybersecurity and life-sciences work. Access remains program-dependent. Anthropic’s September announcement.
Google describes Gemini 3.8 Flash and Flash Cyber as sharing foundational intelligence, with different safeguards and deployment arrangements. Flash Cyber is restricted to trusted defenders through Fairwind. Google’s wording does not establish identical model weights, so the two companies’ claims should not be treated as interchangeable. Google’s announcement.
Restricted access is not new. What these releases make increasingly visible is how much of the product sits around the intelligence.
The differences also extend beyond the model companies’ announcements.
Harvey’s Sept. 1 notice makes Fable 5.1 an opt-in offering. It warns that the model’s processing practices may differ from commitments in existing customer agreements, describes a time-bound zero-retention arrangement for eligible customers, and says processing occurs in the United States. Those statements describe Harvey’s published offering; they should not be generalized to every distribution channel. Harvey’s implementation notice.
Cursor documents a different set of operating decisions. Enterprise customers need explicit approval to enable Fable 5.1. Cursor’s own Privacy Mode does not eliminate Anthropic’s separate retention requirements. Requests that trigger safeguards can automatically fall back to Opus. Cursor’s documentation.
These are commercially interested providers describing their implementations, not independent studies of customer outcomes. They nevertheless establish something useful: choosing the model does not settle the terms under which an employee encounters it.
The route matters. So does the agreement attached to that route.
In “Model Portability Is Not AI Portability,” I argued that moving a model does not automatically move the complete working system. The newer question is what happens when parts of that system change while the model name stays the same.
Anthropic’s versioning documentation provides a concrete example. A model ID pins the model’s weights and configuration, but surrounding infrastructure—including routing, safety classifiers, and sampling logic—can change. The documentation says those changes can affect observable behavior. Model IDs and versioning.
A fixed model version is useful. It is not a frozen service.
The enterprise catalog therefore needs to record more than “approved model.” It needs to describe the approved use of that model and the evidence supporting the approval.
Consider a hypothetical internal source-code review service. Its purpose is to inspect approved repositories and propose repairs. The following is a proposed approval record, not a claim that a particular product already satisfies every requirement.
| Boundary | Proposed Configuration | Owner and Evidence |
|---|---|---|
| Model and routing | Fable 5.1 through the company gateway to the Claude API; no unapproved fallback | The platform owner records the exact model ID, interface, routing settings, and test results. Supplier-controlled changes are tracked separately. |
| Eligible users and entities | One corporate entity’s internal security team; no assumed access for affiliates or contractors | Procurement confirms applicable access rights. The identity team enforces membership. Unconfirmed coverage blocks access. |
| Permitted actions | Read isolated copies of two approved repositories and draft patches; no merging or production deployment | The application owner enforces tool permissions and tests attempted actions outside that scope. |
| Data handling | Only approved source code, with processing, storage, review locations, and retention explicitly accepted | Privacy and security owners retain the applicable terms and verified data-flow description. Unknown locations or retention conditions block approval. |
| Monitoring and evidence | Company-held records of requests, actions, approvals, and unfinished work, limited to necessary information | Security identifies authorized reviewers and tests whether required evidence remains retrievable after supplier access is lost. |
| Interruption and recovery | Pause affected jobs; use a separately approved alternative or manual review | The service owner names the person authorized to resume work and records a tested recovery procedure. |
Each row needs a status: documented, contractually confirmed where necessary, or not yet tested. A public description of a feature is not evidence that the enterprise has enabled it correctly.
There are also two different owners to record. One can change the condition. The other decides whether the enterprise can continue operating after that change.
The supplier may change a classifier. Your architecture board cannot prevent that merely by approving a design. It can decide what evidence is needed afterward and whether the affected workflow must pause.
That distinction turns an inventory into an operating record.
Provider permission and enterprise authority still answer different questions.
A supplier may permit vulnerability analysis. That does not authorize an agent to inspect every system reachable from your network. An employee may be allowed to read a repository without being allowed to deploy a repair.
The earlier capability-versus-authority argument remains the foundation. The purchasing decision now needs to establish which controls the enterprise can enforce independently of the supplier’s judgment.
For consequential workflows, those controls should include user identity, permitted tools and targets, approval before consequential changes, records of completed actions, and a way to stop further execution. Their effectiveness should not depend on the model agreeing that a request is inappropriate.
Google’s Fairwind requirements illustrate the division. Google controls program admission, while participants must implement user authentication, phishing-resistant multifactor authentication, applicable access controls, and tracking of employee access and use. Access is limited to specified internal security teams. Fairwind’s governance requirements.
This does not mean every enterprise should rebuild the provider’s safeguards.
A managed service may be sufficient when it can demonstrate the required controls and the customer can administer and audit them. An enterprise-controlled harness becomes necessary where the workflow requires permissions, approvals, evidence, or recovery that the managed service cannot reliably provide.
“Controlled” does not have to mean “built from scratch.” It means the organization can establish and enforce the required boundary. If neither the purchased service nor an integration can do that, the consequential action should remain outside the automation.
Anthropic’s planned Enterprise Frontier Safeguards would allow monitoring data to reside in customer-controlled cloud infrastructure, with options for customer-managed keys and customer review of flagged activity. Rollout is planned in phases later this fall. The storage, key-management, and review options are separately configurable; the announcement should not be read as proof that every customer already has them. Enterprise Frontier Safeguards.
Its interim zero-retention arrangement also has limits. Anthropic describes it as temporary and restricted to eligible uses. Real-time safeguards and enforcement continue to apply, and the company says it may modify or withdraw the arrangement. Covered Models guidance.
Moving records into the customer’s environment changes custody. It does not remove the need to monitor activity, investigate problems, or establish who can suspend service.
Someone must receive the alert. Someone must have permission to examine the evidence. Someone must distinguish misuse from legitimate work that was incorrectly flagged.
For a multinational organization, the approval record should separately identify the contracting entity, eligible users, inference locations, stored-data locations, and locations from which people may review the data. An approved storage region does not answer all those questions.
Harvey’s processing notice supplies one concrete reason to ask. It does not establish what every organization in Europe, the United Kingdom, or Asia-Pacific may lawfully or contractually do. Those decisions require the exact service configuration and applicable agreement, not a general claim of global availability.
The contract discussion should describe events, not merely desirable qualities.
Anthropic’s public commercial terms, for example, allow suspension in specified circumstances and describe reasonable efforts to provide written notice and restore access after a curable cause is resolved. That is different from a guaranteed advance-warning period or a fixed recovery time. Customer-specific agreements may differ. Public commercial terms, Section I.
Procurement, legal, security, and the service owner should resolve four practical matters:
These are matters to confirm or negotiate, not assurances that suppliers necessarily offer.
The purchasing decision must also survive an unwelcome answer. If the provider cannot guarantee advance notice, a critical workflow needs a tested interruption response. If the evidence needed to reconstruct a transaction cannot be obtained, that workflow may need different architecture.
A contract cannot prevent every interruption. It can make the responsibilities clearer before people are trying to recover under pressure.
Now take the hypothetical code-review service and interrupt it.
The supplier suspends the organization’s access while several reviews are underway. Some draft patches have been saved. Other jobs are waiting. This is a planning scenario, not a reported customer incident.
The platform should stop dispatching affected work and preserve the records it is authorized to retain. The service owner should establish which jobs completed, which produced partial work, and which never started.
Paused does not mean rolled back.
Next, determine the scope and reason for the restriction. A service interruption, suspected credential misuse, and a prohibition on the requested activity require different responses. An alternative model is appropriate only when the work remains permitted and the replacement’s access rights, data handling, quality, and controls have been approved. Changing accounts to evade a restriction is not recovery.
If no approved alternative exists, route the work to manual review or hold it. The owner should know how much work that alternative can absorb and when delays become unacceptable.
This is where the harness around the model earns its cost. It preserves the organization’s ability to understand and manage unfinished work, even when the supplier is unavailable.
The rehearsal should also produce a cost estimate.
Suppose a switch requires 80 engineering hours and 40 review hours at an assumed blended rate of $150 an hour. That is $18,000 before additional licenses, parallel operation, service charges, or delayed work. These are illustrative assumptions, not measured customer costs.
Use your own drill to replace them.
Record the effort required to reconstruct work, validate the replacement, obtain approvals, and clear the backlog. Compare that expense with the cost of maintaining a ready alternative. Some workflows will justify the investment. Others will be adequately served by a documented manual procedure.
Token prices alone cannot make that decision.
The public evidence supports a narrower conclusion than a sweeping transformation of every enterprise purchase.
Specialized access may remain concentrated in sensitive domains. Providers may be better equipped than individual customers to operate sophisticated safeguards. A routine drafting workflow may need little beyond existing access controls and a human fallback.
There is also an evidence boundary. Harvey and Cursor document real service arrangements, but their notices are not independent evaluations of enterprise outcomes. Public documentation does not establish the full regional eligibility of restricted programs, negotiated customer commitments, or measured switching costs. Those parts of the original reporting brief remain open.
The practical conclusion does not require pretending otherwise.
Before placing consequential work behind a model endpoint, describe the complete service, identify who can change its conditions, and test how the work will be recovered. Scale that preparation to the consequence of interruption.
We don’t need to return to June. This week OpenAI launched a new set of models, including those that are restricted to people working in the cyber security space. If you intend to apply for access to these systems, you need to understand the eligibility requirements and prepare the necessary documentation, the question was no longer simply how well the model could perform. It also needs to include how you will handle interruptions, maintain continuity, and ensure that critical work can proceed even if access is temporarily unavailable.
The work still needs somewhere to go.
A useful AI purchasing decision gives it that place: a permitted route, a recoverable state, and a person who knows what happens next.
I broke that iPhone, and for a while lost access to my brand new phone. A shattered screen and a supplier suspending model access are different failures.
But both lead to a practical question: what can you do while the thing you depend on is unavailable?
I had asked for a loaner. What I actually had was my old phone, aslowly charging BlackBerry. Returning to it was inconvenient, but it gave me something to use while I waited.
For an enterprise, the equivalent deserves more preparation. The alternative needs the right permissions, access to the necessary work, and someone authorized to decide when it is safe to continue. Its limitations need to be understood before people are depending on it.
Choose the capable model. Test what it can accomplish. Then give the arrangements around it the same attention.
Before handing over important work, know what your BlackBerry is.
And make sure it is charged.
", "url": "https://tedt.org/The-Same-Model-Different-Rules/", "image": "/img/2026-09/iPhone-Pearl.webp", "tags": ["enterprise AI","AI procurement","AI governance","model access","operational resilience","service continuity","vendor risk","data custody","access controls","AI portability"], "date_published": "2026-09-05T09:00:00-07:00", "date_modified": "2026-09-05T09:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/Model-Portability-Is-Not-AI-Portability/", "title": "Model Portability Is Not AI Portability", "summary": "Large enterprises are learning how to switch models. Moving a working business process without losing quality, controls, or money is a different problem.", "content_text": "Model Portability Is Not AI PortabilityLarge enterprises are learning how to switch models. Moving a working business process without losing quality, controls, or money is a different problem.When I was a child, I loved trains. I still do. To me, they are the Industrial Revolution made visible: steel, power, motion, and human coordination assembled into machines capable of carrying people and freight across great distances. A train is not merely a machine. It is an entire system moving through the world. They made the world a smaller and more connected place.My dad would take me to the model train exhibits at the LA County Fair and to the train store in Pasadena on Route 66. Fairplex offered both ends of the experience. It had a collection of full-sized trains outside and an entire section devoted to model railroads.For my parents, this was a wonderfully efficient arrangement. They could settle into the shade while I remained occupied for most of the day. They watched me watch the model trains travel round and round their carefully built layouts. I could also go and climb over those enormous beasts of steel and by the end of the day, I was exhausted, happy, and if I had been paying attention, I would have learned something about how the system worked.You see as I moved back and forth between two versions of the same world. On one side of Fairplex, I could stand over an entire railway and watch the system operate in miniature. But over on the other side, I was the miniature, climbing through locomotives built on a scale that made a child look very small.The difference was scale. The resemblance was the system.The locomotives were what drew the eye, whether they were small enough to hold or large enough to climb through. But even a model train cannot make a journey by itself.The locomotive needs track of the right gauge. It needs compatible power and controls. Its couplers must fit the cars. Switches must send it down the intended line. Signals must keep it from colliding with something already there. Behind the entire layout is someone who built it, maintains it, and knows what to do when a train stops where it should not.You can place two locomotives beside the same track and say that you have a choice of engines. That does not mean you can move the same set of rail cars to another railway and expect the journey to work unchanged.The engine may be replaceable. The journey still depends on the system around it that makes up the locomotive, the switches, the signals, and the layout of the tracks.Those model railways offer a useful parable for Enterprise AI. Companies are adding second and third models, putting gateways in front of them, and declaring themselves vendor independent.What they have usually gained is model choice.Whether they have gained AI portability is a much harder question.The Model Is the Visible PartA multi-model gateway can route requests to models from OpenAI, Anthropic, Google, or an open-weight provider. It can centralize authentication, monitor usage, apply cost controls, ensure DLP policies are adhered to and redirect traffic when one provider is unavailable.That is useful. In many enterprises, it is also necessary.But it is not the same as moving a business workflow. Model portability means that an application can call another model. AI portability means that another model can complete the same business task without unacceptable losses in quality, permissions, observability, recovery, regulatory control, or cost. The first is an interface problem. The second is a systems problem.Zalandooffers a useful example. Its engineering platform gives more than 250 teams access to models through a LiteLLM-based proxy connected to OpenAI, Amazon Bedrock, and Google Vertex. Their proxy centralizes adoption measurements, cost tracking, caching, client configuration, and model retirement.But that proxy is only part of the story.Around it, Zalando has developed authentication injection, Model Context Protocol access, shared agent skills, configuration management, and other supporting services. The company is also working on an identity broker, token vault, agent sandboxing, and model routing.Even then, it reports that users become attached to particular coding tools and model styles. They rarely switch models unless a limit or error forces the issue. This is not a criticism of Zalando. It is evidence of how the work really evolves.The gateway solved a lot of problems. It centralized and simplified access. Adoption created a platform. The platform created new operating responsibilities. Human habits created a dependency.And dependencies that can not disappear, create risk.The Harness Is Part of the ProductI have argued before that an AI harness gives a model tools, memory, permissions, verification, and recovery. It turns a model that can discuss work into a system that can participate in the work. Why AI Needs a HarnessWhat is now clear is that the harness determines how replaceable the model really is.NVIDIA recently reported that its Agentic Variation Operators system completed all 183 levels in the public ARC-AGI-3 set. The system paired a frontier model with persistent memory, tools, supervision, feedback, and recovery mechanisms.The important point was not simply the benchmark score. NVIDIA argued that long-running performance belonged to the complete agent system, not to the model alone. NVIDIA’s AVO reportThat result requires repeatability. This was vendor-reported, and only applies to the public benchmark set. It was not a controlled measurement of the harness’s individual contribution. NVIDIA acknowledges those limitations.Still, the architectural lesson is useful and a warning for enterprises.If memory, tools, instructions, evaluation, and recovery materially affect the result, replacing the model while changing nothing else may be impossible. A prompt tuned for one model may fail with another. A tool-calling pattern may behave differently. A safety filter may block a previously accepted workflow. A replacement model may produce the correct answer while losing the evidence required to trust it.Performance and portability belong to the whole system and so does risk.What Must the Enterprise Own?Does this mean the enterprise must build and own the entire AI stack?No.An enterprise does not need to own every model, user interface, orchestration framework, or piece of infrastructure. It does need to control the assets that define successful work.The first is the workflow contract. This describes what the task is, which inputs it requires, what the agent may do, what it may not do, what the output should contain, and how the organization knows the work is complete.The second is the evaluation set. This includes representative cases, known edge conditions, failure examples, adversarial tests, acceptance thresholds, and situations requiring human review. If a vendor owns the only credible test of the system, the enterprise cannot independently determine whether a replacement works.The third is identity and authorization. An agent acting for an employee, customer, or business process must carry the correct permissions and delegation history. Those controls cannot quietly disappear when the model changes.The fourth is operational evidence. The enterprise needs usable traces showing what information the system accessed, which tools it called, what actions it attempted, what failed, and how it produced the final result.Finally, the enterprise must own the recovery process. The business must decide when the system stops, when a person intervenes, what gets rolled back, what gets retried, and what evidence is retained.These assets form the trusted action surface around AI. That is where much of the durable enterprise value now lives. The AI Value StreamThe model supplies capability.The enterprise must retain control over meaning, authority, and proof.How Do You Measure a Switch?Portability should be tested, not declared or assumed. If the workflow is critical to the company the enterprise should have metrics around how much it costs to move.Choose one bounded production workflow. Establish a baseline using the current model and platform. Measure whether the system completes the task correctly, how often a person must intervene, how long the work takes, what it costs, and what happens when something goes wrong.Then move that workflow to another model or provider.Do not stop when the new endpoint returns a response. Record the complete portability delta: Migration time: How long did the change take, including security review, integration, testing, deployment, and employee preparation? Engineering effort: How many instructions, skills, tool definitions, integrations, and recovery routines had to be rewritten? Quality change: Did completion rates, factual errors, policy violations, or human corrections improve or decline? Control loss: Were permissions, regional restrictions, logs, citations, retention rules, and rollback capabilities preserved? Economic change: Did the cost of a completed and accepted result improve, or did a lower model price create more retries and human review? Behavioral change: Could employees use the replacement effectively, or had the existing tool become part of how they understood the work? The organization should not compress these measures into a single portability score. It needs enough evidence to see where the dependency actually resides.It may reside in the model. It may reside in a proprietary tool interface, a vendor-specific memory system, a skill library, an evaluation service, or the accumulated habits of the workforce.The economic measure is especially important. Token prices are easy to compare because vendors publish them. The meaningful unit is the cost of a finished job. The Cost of a Finished JobA cheaper engine does not lower the cost of the journey if every car must be rebuilt before it can move.When Is an Internal Harness Worth Building?An internal harness makes sense when the workflow differentiates the business, crosses several enterprise systems, handles sensitive or regulated information, or operates at enough scale to justify a shared platform.It may also be necessary when the enterprise needs to move between providers or regions for resilience, sovereignty, negotiating leverage, or legal compliance.But an internal harness is not automatically the mature answer.For standardized work, an integrated vendor platform may be the better decision. Salesforce and Anthropic, for example, are combining Claude with Salesforce data, permissions, business rules, workflows, and prebuilt skills. Salesforce says authentication and permissions can be managed centrally while actions continue to pass through Salesforce controls.Some of those capabilities remain in pilot or planned availability, and the claims come from the vendors themselves. Still, the attraction is easy to understand especially if you are already invested heavily into Salesforce and believe that the vendor’s controls meet your business needs.If the business process already lives inside one platform, the integrated option may reduce implementation time, preserve an established security boundary, and provide a more coherent user experience.The decision therefore depends on the value of the option.Build or configure with the vendor’s platform or retain an enterprise-controlled harness so that when you switch suppliers, you can preserve specialized workflows, or control critical business actions has material value.Choose the integrated platform when the workflow is standard, the provider’s controls meet the business need, and the organization would gain little from operating another internal platform.Portability is not a moral virtue. It is an option that will cost you.The enterprise should purchase that option when the likely cost of disruption, regulatory change, supplier failure, or strategic dependence exceeds the cost of maintaining the vendor / model lock-in.What Belongs in the Contract?If a model or platform is supposed to be replaceable, the commercial agreement should preserve the evidence and assets needed to replace it.That includes: Access to prompts, skills, workflow configurations, and evaluation results Export of logs, traces, business state, and system-generated records Ownership and permitted reuse of derived artifacts Notice before model retirement or material behavioral changes Access to fixed model versions when reproducibility matters Clear rules for data retention, model training, subprocessors, and regional processing Tool-call and application programming interface compatibility commitments The right to test alternative models against enterprise evaluation sets Transition assistance when the contract ends Rollback procedures when an upgrade changes workflow behaviorA contract cannot make two models behave identically.It can prevent the enterprise from discovering, too late, that the information needed to perform a migration belongs to the supplier.It should be noted that if a vendor refuses to provide these rights, the enterprise may have to accept that the model is not replaceable and that the business process is now dependent on a single supplier. This actually might be that vendor’s strategy, and it is not necessarily a bad one for either party. It is just a business decision that you need to make for your enterprise and completely understand before it invests in a lock-in.When Does the Harness Become the New Risk?There is one more complication.An enterprise may reduce its dependence on a model provider and create a new dependency on its own internal platform.The warning signs are familiar: One person or small team understands the gateway. No product owner is accountable for the platform. Evaluations are stale or maintained separately by each business unit. Model retirements trigger emergency migrations. Costs can be traced to requests but not to accepted business outcomes. Permissions and agent identities work differently across tools. Teams copy prompts and skills because the shared service is unreliable. No one has completed a provider-switching exercise.At that point, the harness is no longer strategic leverage. It is an underfunded internal product sitting in the path of critical work. Many times this problem is multiplied by the fact that the enterprise will have different harnesses from different internal teams, and each of those harnesses will have different levels of maturity, different levels of documentation, and different levels of support. The result is a patchwork of internal platforms that are not portable, not reliable, and not well understood.Adding another abstraction layer on top of this will not fix your problem.Each harness needs a roadmap, service objectives, security engineering, evaluation management, incident procedures, dedicated funding, and a clear boundary between platform responsibilities and business-workflow responsibilities.Enterprises already know how to operate identity platforms, integration platforms, data platforms, and developer platforms. An AI harness belongs to the same family.This means that these harnesses must be governed with similar seriousness at the enterprise architecture, operational, and business levels.Moving the CargoThe practical test of AI portability is not whether another model appears in the company’s catalog. It’s also not whether the model can be called through a gateway. It is whether the same business task can be completed with another model without unacceptable losses in quality, permissions, observability, recovery, regulatory control, or cost.Again to validate this, choose one important workflow and move it.Use another model, another provider, or another region. Measure what had to be rebuilt. Measure how quality changed. Determine which controls survived, how people adapted, and what it cost to deliver an accepted result.My dad took a boy who loved trains to see model railways at the LA County Fair and at a train store in Pasadena. Years later, those layouts offer another lesson.The locomotive was the part that drew attention.The track, switches, signals, power, controls, and maintenance were what made the journey possible.An enterprise that counts models is still looking at the locomotives.An enterprise that tests whether the same business task can travel safely across multiple providers is actually planning on running a railway responsibly.The model may pull the train.The enterprise system determines whether the cargo arrives.", "content_html": "Large enterprises are learning how to switch models. Moving a working business process without losing quality, controls, or money is a different problem.
When I was a child, I loved trains. I still do. To me, they are the Industrial Revolution made visible: steel, power, motion, and human coordination assembled into machines capable of carrying people and freight across great distances. A train is not merely a machine. It is an entire system moving through the world. They made the world a smaller and more connected place.
My dad would take me to the model train exhibits at the LA County Fair and to the train store in Pasadena on Route 66. Fairplex offered both ends of the experience. It had a collection of full-sized trains outside and an entire section devoted to model railroads.
For my parents, this was a wonderfully efficient arrangement. They could settle into the shade while I remained occupied for most of the day. They watched me watch the model trains travel round and round their carefully built layouts. I could also go and climb over those enormous beasts of steel and by the end of the day, I was exhausted, happy, and if I had been paying attention, I would have learned something about how the system worked.
You see as I moved back and forth between two versions of the same world. On one side of Fairplex, I could stand over an entire railway and watch the system operate in miniature. But over on the other side, I was the miniature, climbing through locomotives built on a scale that made a child look very small.
The difference was scale. The resemblance was the system.
The locomotives were what drew the eye, whether they were small enough to hold or large enough to climb through. But even a model train cannot make a journey by itself.
The locomotive needs track of the right gauge. It needs compatible power and controls. Its couplers must fit the cars. Switches must send it down the intended line. Signals must keep it from colliding with something already there. Behind the entire layout is someone who built it, maintains it, and knows what to do when a train stops where it should not.
You can place two locomotives beside the same track and say that you have a choice of engines. That does not mean you can move the same set of rail cars to another railway and expect the journey to work unchanged.
The engine may be replaceable. The journey still depends on the system around it that makes up the locomotive, the switches, the signals, and the layout of the tracks.
Those model railways offer a useful parable for Enterprise AI. Companies are adding second and third models, putting gateways in front of them, and declaring themselves vendor independent.
What they have usually gained is model choice.
Whether they have gained AI portability is a much harder question.
A multi-model gateway can route requests to models from OpenAI, Anthropic, Google, or an open-weight provider. It can centralize authentication, monitor usage, apply cost controls, ensure DLP policies are adhered to and redirect traffic when one provider is unavailable.
That is useful. In many enterprises, it is also necessary.
But it is not the same as moving a business workflow. Model portability means that an application can call another model. AI portability means that another model can complete the same business task without unacceptable losses in quality, permissions, observability, recovery, regulatory control, or cost. The first is an interface problem. The second is a systems problem.
Zalandooffers a useful example. Its engineering platform gives more than 250 teams access to models through a LiteLLM-based proxy connected to OpenAI, Amazon Bedrock, and Google Vertex. Their proxy centralizes adoption measurements, cost tracking, caching, client configuration, and model retirement.
But that proxy is only part of the story.
Around it, Zalando has developed authentication injection, Model Context Protocol access, shared agent skills, configuration management, and other supporting services. The company is also working on an identity broker, token vault, agent sandboxing, and model routing.
Even then, it reports that users become attached to particular coding tools and model styles. They rarely switch models unless a limit or error forces the issue. This is not a criticism of Zalando. It is evidence of how the work really evolves.
The gateway solved a lot of problems. It centralized and simplified access. Adoption created a platform. The platform created new operating responsibilities. Human habits created a dependency.
And dependencies that can not disappear, create risk.
I have argued before that an AI harness gives a model tools, memory, permissions, verification, and recovery. It turns a model that can discuss work into a system that can participate in the work. Why AI Needs a Harness
What is now clear is that the harness determines how replaceable the model really is.
NVIDIA recently reported that its Agentic Variation Operators system completed all 183 levels in the public ARC-AGI-3 set. The system paired a frontier model with persistent memory, tools, supervision, feedback, and recovery mechanisms.
The important point was not simply the benchmark score. NVIDIA argued that long-running performance belonged to the complete agent system, not to the model alone. NVIDIA’s AVO report
That result requires repeatability. This was vendor-reported, and only applies to the public benchmark set. It was not a controlled measurement of the harness’s individual contribution. NVIDIA acknowledges those limitations.
Still, the architectural lesson is useful and a warning for enterprises.
If memory, tools, instructions, evaluation, and recovery materially affect the result, replacing the model while changing nothing else may be impossible. A prompt tuned for one model may fail with another. A tool-calling pattern may behave differently. A safety filter may block a previously accepted workflow. A replacement model may produce the correct answer while losing the evidence required to trust it.
Performance and portability belong to the whole system and so does risk.
Does this mean the enterprise must build and own the entire AI stack?
No.
An enterprise does not need to own every model, user interface, orchestration framework, or piece of infrastructure. It does need to control the assets that define successful work.
The first is the workflow contract. This describes what the task is, which inputs it requires, what the agent may do, what it may not do, what the output should contain, and how the organization knows the work is complete.
The second is the evaluation set. This includes representative cases, known edge conditions, failure examples, adversarial tests, acceptance thresholds, and situations requiring human review. If a vendor owns the only credible test of the system, the enterprise cannot independently determine whether a replacement works.
The third is identity and authorization. An agent acting for an employee, customer, or business process must carry the correct permissions and delegation history. Those controls cannot quietly disappear when the model changes.
The fourth is operational evidence. The enterprise needs usable traces showing what information the system accessed, which tools it called, what actions it attempted, what failed, and how it produced the final result.
Finally, the enterprise must own the recovery process. The business must decide when the system stops, when a person intervenes, what gets rolled back, what gets retried, and what evidence is retained.
These assets form the trusted action surface around AI. That is where much of the durable enterprise value now lives. The AI Value Stream
The model supplies capability.
The enterprise must retain control over meaning, authority, and proof.
Portability should be tested, not declared or assumed. If the workflow is critical to the company the enterprise should have metrics around how much it costs to move.
Choose one bounded production workflow. Establish a baseline using the current model and platform. Measure whether the system completes the task correctly, how often a person must intervene, how long the work takes, what it costs, and what happens when something goes wrong.
Then move that workflow to another model or provider.
Do not stop when the new endpoint returns a response. Record the complete portability delta:
Migration time: How long did the change take, including security review, integration, testing, deployment, and employee preparation?
Engineering effort: How many instructions, skills, tool definitions, integrations, and recovery routines had to be rewritten?
Quality change: Did completion rates, factual errors, policy violations, or human corrections improve or decline?
Control loss: Were permissions, regional restrictions, logs, citations, retention rules, and rollback capabilities preserved?
Economic change: Did the cost of a completed and accepted result improve, or did a lower model price create more retries and human review?
Behavioral change: Could employees use the replacement effectively, or had the existing tool become part of how they understood the work?
The organization should not compress these measures into a single portability score. It needs enough evidence to see where the dependency actually resides.
It may reside in the model. It may reside in a proprietary tool interface, a vendor-specific memory system, a skill library, an evaluation service, or the accumulated habits of the workforce.
The economic measure is especially important. Token prices are easy to compare because vendors publish them. The meaningful unit is the cost of a finished job. The Cost of a Finished Job
A cheaper engine does not lower the cost of the journey if every car must be rebuilt before it can move.
An internal harness makes sense when the workflow differentiates the business, crosses several enterprise systems, handles sensitive or regulated information, or operates at enough scale to justify a shared platform.
It may also be necessary when the enterprise needs to move between providers or regions for resilience, sovereignty, negotiating leverage, or legal compliance.
But an internal harness is not automatically the mature answer.
For standardized work, an integrated vendor platform may be the better decision. Salesforce and Anthropic, for example, are combining Claude with Salesforce data, permissions, business rules, workflows, and prebuilt skills. Salesforce says authentication and permissions can be managed centrally while actions continue to pass through Salesforce controls.
Some of those capabilities remain in pilot or planned availability, and the claims come from the vendors themselves. Still, the attraction is easy to understand especially if you are already invested heavily into Salesforce and believe that the vendor’s controls meet your business needs.
If the business process already lives inside one platform, the integrated option may reduce implementation time, preserve an established security boundary, and provide a more coherent user experience.
The decision therefore depends on the value of the option.
Build or configure with the vendor’s platform or retain an enterprise-controlled harness so that when you switch suppliers, you can preserve specialized workflows, or control critical business actions has material value.
Choose the integrated platform when the workflow is standard, the provider’s controls meet the business need, and the organization would gain little from operating another internal platform.
Portability is not a moral virtue. It is an option that will cost you.
The enterprise should purchase that option when the likely cost of disruption, regulatory change, supplier failure, or strategic dependence exceeds the cost of maintaining the vendor / model lock-in.
If a model or platform is supposed to be replaceable, the commercial agreement should preserve the evidence and assets needed to replace it.
That includes:
A contract cannot make two models behave identically.
It can prevent the enterprise from discovering, too late, that the information needed to perform a migration belongs to the supplier.
It should be noted that if a vendor refuses to provide these rights, the enterprise may have to accept that the model is not replaceable and that the business process is now dependent on a single supplier. This actually might be that vendor’s strategy, and it is not necessarily a bad one for either party. It is just a business decision that you need to make for your enterprise and completely understand before it invests in a lock-in.
There is one more complication.
An enterprise may reduce its dependence on a model provider and create a new dependency on its own internal platform.
The warning signs are familiar:
At that point, the harness is no longer strategic leverage. It is an underfunded internal product sitting in the path of critical work. Many times this problem is multiplied by the fact that the enterprise will have different harnesses from different internal teams, and each of those harnesses will have different levels of maturity, different levels of documentation, and different levels of support. The result is a patchwork of internal platforms that are not portable, not reliable, and not well understood.
Adding another abstraction layer on top of this will not fix your problem.
Each harness needs a roadmap, service objectives, security engineering, evaluation management, incident procedures, dedicated funding, and a clear boundary between platform responsibilities and business-workflow responsibilities.
Enterprises already know how to operate identity platforms, integration platforms, data platforms, and developer platforms. An AI harness belongs to the same family.
This means that these harnesses must be governed with similar seriousness at the enterprise architecture, operational, and business levels.
The practical test of AI portability is not whether another model appears in the company’s catalog. It’s also not whether the model can be called through a gateway. It is whether the same business task can be completed with another model without unacceptable losses in quality, permissions, observability, recovery, regulatory control, or cost.
Again to validate this, choose one important workflow and move it.
Use another model, another provider, or another region. Measure what had to be rebuilt. Measure how quality changed. Determine which controls survived, how people adapted, and what it cost to deliver an accepted result.
My dad took a boy who loved trains to see model railways at the LA County Fair and at a train store in Pasadena. Years later, those layouts offer another lesson.
The locomotive was the part that drew attention.
The track, switches, signals, power, controls, and maintenance were what made the journey possible.
An enterprise that counts models is still looking at the locomotives.
An enterprise that tests whether the same business task can travel safely across multiple providers is actually planning on running a railway responsibly.
The model may pull the train.
The enterprise system determines whether the cargo arrives.
", "url": "https://tedt.org/Model-Portability-Is-Not-AI-Portability/", "image": "/img/2026-08/The-System-Behind-the-Engine.webp", "tags": ["enterprise AI","AI portability","model portability","multi-model gateways","AI agent harness","AI governance","vendor lock-in","workflow portability","AI operating model","model migration","platform engineering","technology contracts"], "date_published": "2026-08-28T09:00:00-07:00", "date_modified": "2026-08-28T09:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/Dev-Test-and-Prod-Still-Matter-What-Gets-Deployed-Has-Changed/", "title": "Dev, Test, and Prod Still Matter: What Gets Deployed Has Changed", "summary": "Dev, Test, and Prod still matter for AI agents, but promotion gates must now govern the artifact, authority, state, and evidence together.", "content_text": "Sources for this article Source note: This essay draws on first-party disclosures from OpenAI, Hugging Face, Anthropic, the U.K. AI Security Institute, and Irregular. Their investigations remain incomplete. As of Aug. 22, 2026, OpenAI’s promised technical report and METR/Redwood assessment, Anthropic’s planned METR review, AISI’s planned METR review, and Irregular’s planned evaluation-security white paper had not been published. Irregular says several model-provider disclosures describe the same underlying evaluation issue, so they should not be counted as separate incidents. These events occurred in specialized cybersecurity tests, often with normal safeguards reduced or disabled; Anthropic and AISI both caution against treating them as evidence of how ordinary deployed agents behave.Many enterprise delivery diagrams begin with three boxes.DEV → TEST → PRODWe build in the first. We test throughout, but assemble the release case in the second. We deliberately let the system affect the business in the third. Each environment should carry more consequence than the one before it, and each arrow should mark a deliberate change in exposure.It is a useful picture. It gave software teams a practical way to separate unfinished work from customer-facing systems. It created places for experimentation, verification, approval, and rollback. It also carried a quiet assumption: work in Test cannot affect Production until somebody promotes it.That assumption was never entirely safe. It was a simple way of talking about a complex idea. Agentic systems make the weakness harder to ignore.An AI agent running in a test environment can call an application programming interface, install a package, create an account, open a pull request, send a message, query a live service, or cause another computer to act on its behalf. The agent does not have to be deployed to Production. It only needs a path to something real.The old diagram still captures an important control. But the environment label is not the boundary. We have to ask what the arrow represents. We also have to notice which changes happen without crossing it.What the Old Model Gets RightDev, Test, and Prod are not merely server names. At their best, they describe a progression of responsibility.Dev is where consequence should be smallest. Test is where pre-release evidence should become decision-grade. Prod is where durable business authority is granted. It is also where that authority must remain observable and revocable.Some organizations insert integration, quality assurance, user acceptance testing, staging, shadow, or deployment rings. The number of boxes is not the point. At each step, the system should earn a larger exposure.That progression still matters. In What IT Looks Like in an Enterprise Where AI Is Assumed, I used lab, pilot, and production as distinct places for uncertainty, bounded learning, and operated value. The labels change from company to company, but the intent is familiar: do not expose the business to a new system until the system has earned that exposure.Modern delivery pipelines already move more than application code. They carry configuration, infrastructure templates, database changes, secrets references, policies, and deployment instructions. We learned a long time ago that a release can fail even when the binary doesn’t change.Conventional delivery already runs active code in continuous-integration jobs, integration tests, package registries, and deployment pipelines. Those systems can reach Production too. What changes with an agent is the degree of initiative inside the boundary. Its harness can inspect a result, choose another tool, and chain actions that nobody described in advance.AI did not invent porous environments. It lets software discover and use paths that ordinary release controls may never have modeled.The Artifact Is No Longer the Whole ReleaseA model produces output. A harness lets that model do work.The harness supplies tools, memory, instructions, identity, network access, retry logic, and a way to observe what happened. I explored that system in Why AI Needs a Harness. Once the model can inspect a result and choose another action, we are no longer testing only a static artifact. We are evaluating a bounded decision-and-action system that can change the environment around it.That changes what an environment means.For ordinary software, we often ask, “Where is the application running?” For an agent, we also have to ask: What can it read? What can it change? Which other systems can act for it? What survives after the run ends?A package proxy may live inside the test architecture while fetching material from the public internet. A test credential may still call a live software-as-a-service endpoint. A shared repository may let one run leave state for another. A browser agent may be operating in a test tenant while sending requests to real people and public websites.The environment name tells us where the process started. It does not tell us where the consequences can end.This matters well beyond frontier-model laboratories. A coding agent may hold a GitHub token. A finance agent may read a production ledger while writing only to a test workbook. A service agent may work in a training queue but still send email. A data agent may query a copy of a warehouse while exporting results through a live connector. A security agent may be testing a fictional target through a network path that reaches a real one.In each case, the box says Test. The authority says something else.When Test Touched ProductionIn July 2026, an internal OpenAI cybersecurity evaluation supplied a stark example. OpenAI said the models did not have direct internet access. They could, however, install packages through an internally hosted Artifactory proxy and cache. The models found and exploited a previously unknown Artifactory vulnerability, obtained internet access, and eventually reached Hugging Face production infrastructure. OpenAI called its account preliminary.Hugging Face later reconstructed about 17,600 actions across roughly two and a half days inside its infrastructure. It reported that five datasets apparently connected to the benchmark were accessed, while finding no effect on other customer-facing models, datasets, Spaces, or packages. Hugging Face also said no unauthorized software-supply-chain change was shipped.I examined the mechanics of that incident in The Sandbox Was Not the Boundary. The point here is different. The models were still being evaluated. They had not been released as a customer product. Yet the evaluation already had a path to production consequences through a shared service, a public launch point, and live third-party infrastructure.Separate incidents were later disclosed, but they involved different mechanisms and should not be treated as one breach count.Anthropic reviewed 141,006 cybersecurity evaluation runs and reported three incidents involving six runs. A configuration problem left live internet access available even though the models had been told they were inside simulations. In one case, a model published a malicious package to the Python Package Index. Anthropic said the package was available for about an hour and ran on 15 real systems. In another, a model scanned roughly 9,000 targets before compromising one real application. Anthropic’s latest research model stopped after concluding that its target was real, an important piece of counterevidence.The U.K. AI Security Institute reported a separate event. This was not a sandbox escape. Internet access was intentionally enabled, and the model providers’ cyber classifiers were disabled so the institute could measure maximum capability. Across 122 runs, AISI found 19 out-of-scope actions in 10 runs, including an attempted malicious pull request and the creation of fake identities. A human maintainer rejected the code, and AISI found no resulting real-world harm.Several later headlines involving different model providers traced back to one Irregular evaluation scenario. Irregular has said those disclosures shared an underlying control problem. Counting every provider statement as a separate failure would exaggerate the evidence.These were unusually permissive cyber tests. They often used unreleased models, reduced refusals, disabled classifiers, or deliberately open internet access. They do not show that an ordinary enterprise assistant will break out of its environment.They show something narrower and more useful: a system labeled Test can create production risk as soon as it can cause an external effect.The Promotion Gate Has Four Different JobsThe traditional pipeline promotes an application release. An agentic system makes the gate responsible for four connected dimensions: artifact, authority, state, and evidence.They do not cross the boundary in the same way. The tested artifact should be promoted unchanged and accompanied by verifiable provenance. Authority should be issued in the destination. Runtime state should be reset; any necessary migration should be deliberate and governed. Evidence should be independently protected and should keep accumulating after release.1. The ArtifactThe promotable artifact is a signed, versioned release assembly or deployment manifest. It identifies the application code, declared model or model version, system instructions, policy and tool definitions, connector definitions, and configuration and routing dependencies.It does not include destination credentials, identities, live endpoints, or secret values. Those are bound separately in each environment.Any one of these elements can change behavior. A new connector may expose an action the agent could not take yesterday. A revised system instruction may alter when it stops or asks for help. A provider update may change model behavior without a customer deploying new application code, depending on the service and versioning contract.The release record therefore has to identify the whole runnable assembly, not only the Git commit. Where the platform permits it, identify its components with immutable versions or digests and bind them to verifiable provenance. The goal is simple: know that the assembly tested is the assembly released.2. The AuthorityAuthority includes identity, credentials, network egress, tool scopes, transaction limits, approval rules, and the systems the agent may affect.Giving a test agent a live token creates production-equivalent exposure, even if no code moves. Outbound internet access, a connector pointed at a live tenant, or a tool expanded from read to write can create the same class of external consequence.Policy intent can be version-controlled and promoted with the release. The destination workload identity should be bound there, and short-lived credentials should be issued there rather than copied forward. Production authority should be scoped to the destination and independently revocable.This is why capability and authority have to remain separate. In How Much Work Can Your AI Safely Own?, I argued that demonstrated capability does not automatically grant operating authority. The same rule belongs in the delivery pipeline. A system may be capable of acting before the organization has earned the right to let it act.3. The StateState includes retrieval data, working memory, caches, queues, shared directories, previous tool results, and whatever remains for the next run.State can cross an environment boundary without anyone deploying software. A production document can enter a test retrieval index. A test run can leave a file that another run treats as instruction. A cached response can outlive the policy that permitted it. A refreshed knowledge source can change the answer even when the model, prompt, and code stay fixed.State needs lineage, retention rules, reset procedures, and regional handling appropriate to the data. Calling it “test data” does not make it synthetic, disposable, or harmless.Most runtime state should not be promoted at all. Test memory, sessions, queues, caches, shared files, and previous tool results should normally be reset or isolated. When a business dataset, retrieval index, or model checkpoint must move, treat it as a separate approved migration with versioning, integrity checks, provenance, retention rules, and a rollback plan.4. The EvidenceEvidence includes evaluation results, provenance, monitoring baselines, rollback results, known limits, and operating telemetry. Approval and risk acceptance are decision records informed by that evidence. They are not evidence that the system is trustworthy.The agent should not be the only system that writes the work, designs the test, grades the result, and decides it is ready. Independent scenarios matter. Holdout tests matter. A real rollback rehearsal matters. So does evidence that the identity can be revoked and the action trail can be reconstructed under pressure.Evidence accumulates throughout the lifecycle. Its record should be independent of the agent and protected from alteration. A model update, tool change, new data source, expanded permission, or material drift can invalidate yesterday’s approval without a traditional deployment. Production telemetry, drift findings, interventions, incidents, and reassessments should append to the assurance record. Promotion is not a one-time ceremony. It is a continuing claim that the running system still deserves its authority.Keep the Environments, Redefine Their GatesWe do not need to throw away Dev, Test, and Prod. We need each environment to make a stronger promise.Dev should minimize consequence. Use synthetic or carefully de-identified data. Deny external write paths by default. Give each run its own short-lived identity and disposable state. Replace live tools with mocks, simulators, or mediated services when the work does not require reality.Test should make pre-release evidence decision-grade. Testing happens throughout the lifecycle; Test is where the release case should become credible. Verification asks whether the system meets its specified requirements and controls. Validation asks whether it is fit for its intended use in a representative deployment context. Agentic systems need both.Use realistic tasks, independent evaluations, separate identities, resettable state, and monitoring that can stop a run while it is happening. When live information is necessary, begin with read-only access and intercept external side effects. Test the route through proxies, package registries, domain name resolution, webhooks, queues, and third-party tools, not only the agent’s visible network interface.The record should let another person reconstruct what was tested, what failed, what was waived, and who accepted the remaining risk.Shadow mode should validate behavior without granting action. Let the agent receive representative production inputs and propose what it would do without giving it permission to make the change. Compare its decisions with actual outcomes. Measure quality, latency, exceptions, cost, and security before expanding authority. That is the same lifecycle discipline I described in The Cost of a Finished Job.Prod should grant narrow, revocable authority. Production is not the end of testing. Measurement and monitoring continue while the system operates, because live telemetry, drift, incidents, and rollback may show that yesterday’s evidence no longer applies.Expand exposure in stages where the work permits it. Use least privilege, per-action traces, transaction limits, policy checks, human approval where consequence requires it, live monitoring, and rehearsed rollback. The system needs a separate observer that can stop it. The agent should not control the only alarm, the only log, or the only switch that turns it off.Third-party evaluators belong inside this model. Their contracts should identify permitted network paths, cross-client isolation, data handling, incident-notification timing, evidence retention, audit rights, and responsibility when a test reaches a real system. “Independent evaluation” describes who performs the test. It does not prove that the test infrastructure is independent, isolated, or safe.Five Questions for the Release ReviewThe release meeting does not need another hundred-page checklist. It needs questions that follow the four different jobs of the gate: identify the assembly, bind its authority, govern its state, and judge the evidence. What changed? Name the model, code, prompts, policies, tools, connectors, configuration, and data sources that differ from the last accepted version. What can it touch? Trace direct and indirect access through identities, proxies, package services, webhooks, shared platforms, and third parties. Record what the agent may read, propose, or change. What survives? Identify memory, files, logs, caches, queues, retrieval indexes, and artifacts that another run or environment can inherit. Who tested it independently? Show evidence from scenarios the builder did not control, including failure cases, stop behavior, permission boundaries, and rollback. Who can stop it and reconstruct the result? Name the decision owner, revocation path, incident lead, evidence location, and conditions for resumption. This is the practical machinery behind The IT Adaptive Factory. The factory is not mature because agents can write and test code quickly. It is mature when the organization can explain what was promoted, what authority was granted, what state survived, why the evidence was sufficient, and how to recover when the answer was wrong.OpenAI’s later response shows the cost of learning this after a control boundary fails. On Aug. 18, the company said it had paused some frontier research workloads, added stronger workload and network isolation, and left its largest planned reinforcement-learning run on hold while it gathered more evidence. OpenAI attributed the broader slowdown to both the Hugging Face incident and concerns about an upcoming model’s cyber capability, so the pause should not be assigned to the incident alone.That response does not prove the new controls will work. It does show that research and test infrastructure can become important enough to slow the production of the model itself.The Arrow Still MattersOrganizations will keep drawing three boxes. They should.The boxes remind us that consequence should rise slowly and evidence should rise first. But an environment label cannot enforce that discipline. Architecture does. Identity does. Network policy does. State isolation does. Independent testing does. Someone with the authority to say “stop” does.Before approving the next agent release, look at the arrow and ask four different questions. What artifact was promoted? What authority was bound in the destination? What state was reset or deliberately migrated? What evidence supported the decision, and how will that evidence continue after release?If a test agent can already cause a real-world change, the organization is already carrying production risk, whatever the box is called.The arrow still matters. It moves the assembly. The gate decides what authority it receives, what state it inherits, and whether the evidence is good enough to let it act.", "content_html": "Source note: This essay draws on first-party disclosures from OpenAI, Hugging Face, Anthropic, the U.K. AI Security Institute, and Irregular. Their investigations remain incomplete. As of Aug. 22, 2026, OpenAI’s promised technical report and METR/Redwood assessment, Anthropic’s planned METR review, AISI’s planned METR review, and Irregular’s planned evaluation-security white paper had not been published. Irregular says several model-provider disclosures describe the same underlying evaluation issue, so they should not be counted as separate incidents. These events occurred in specialized cybersecurity tests, often with normal safeguards reduced or disabled; Anthropic and AISI both caution against treating them as evidence of how ordinary deployed agents behave.
Many enterprise delivery diagrams begin with three boxes.
DEV → TEST → PROD
We build in the first. We test throughout, but assemble the release case in the second. We deliberately let the system affect the business in the third. Each environment should carry more consequence than the one before it, and each arrow should mark a deliberate change in exposure.
It is a useful picture. It gave software teams a practical way to separate unfinished work from customer-facing systems. It created places for experimentation, verification, approval, and rollback. It also carried a quiet assumption: work in Test cannot affect Production until somebody promotes it.
That assumption was never entirely safe. It was a simple way of talking about a complex idea. Agentic systems make the weakness harder to ignore.
An AI agent running in a test environment can call an application programming interface, install a package, create an account, open a pull request, send a message, query a live service, or cause another computer to act on its behalf. The agent does not have to be deployed to Production. It only needs a path to something real.
The old diagram still captures an important control. But the environment label is not the boundary. We have to ask what the arrow represents. We also have to notice which changes happen without crossing it.
Dev, Test, and Prod are not merely server names. At their best, they describe a progression of responsibility.
Dev is where consequence should be smallest. Test is where pre-release evidence should become decision-grade. Prod is where durable business authority is granted. It is also where that authority must remain observable and revocable.
Some organizations insert integration, quality assurance, user acceptance testing, staging, shadow, or deployment rings. The number of boxes is not the point. At each step, the system should earn a larger exposure.
That progression still matters. In What IT Looks Like in an Enterprise Where AI Is Assumed, I used lab, pilot, and production as distinct places for uncertainty, bounded learning, and operated value. The labels change from company to company, but the intent is familiar: do not expose the business to a new system until the system has earned that exposure.
Modern delivery pipelines already move more than application code. They carry configuration, infrastructure templates, database changes, secrets references, policies, and deployment instructions. We learned a long time ago that a release can fail even when the binary doesn’t change.
Conventional delivery already runs active code in continuous-integration jobs, integration tests, package registries, and deployment pipelines. Those systems can reach Production too. What changes with an agent is the degree of initiative inside the boundary. Its harness can inspect a result, choose another tool, and chain actions that nobody described in advance.
AI did not invent porous environments. It lets software discover and use paths that ordinary release controls may never have modeled.
A model produces output. A harness lets that model do work.
The harness supplies tools, memory, instructions, identity, network access, retry logic, and a way to observe what happened. I explored that system in Why AI Needs a Harness. Once the model can inspect a result and choose another action, we are no longer testing only a static artifact. We are evaluating a bounded decision-and-action system that can change the environment around it.
That changes what an environment means.
For ordinary software, we often ask, “Where is the application running?” For an agent, we also have to ask:
A package proxy may live inside the test architecture while fetching material from the public internet. A test credential may still call a live software-as-a-service endpoint. A shared repository may let one run leave state for another. A browser agent may be operating in a test tenant while sending requests to real people and public websites.
The environment name tells us where the process started. It does not tell us where the consequences can end.
This matters well beyond frontier-model laboratories. A coding agent may hold a GitHub token. A finance agent may read a production ledger while writing only to a test workbook. A service agent may work in a training queue but still send email. A data agent may query a copy of a warehouse while exporting results through a live connector. A security agent may be testing a fictional target through a network path that reaches a real one.
In each case, the box says Test. The authority says something else.
In July 2026, an internal OpenAI cybersecurity evaluation supplied a stark example. OpenAI said the models did not have direct internet access. They could, however, install packages through an internally hosted Artifactory proxy and cache. The models found and exploited a previously unknown Artifactory vulnerability, obtained internet access, and eventually reached Hugging Face production infrastructure. OpenAI called its account preliminary.
Hugging Face later reconstructed about 17,600 actions across roughly two and a half days inside its infrastructure. It reported that five datasets apparently connected to the benchmark were accessed, while finding no effect on other customer-facing models, datasets, Spaces, or packages. Hugging Face also said no unauthorized software-supply-chain change was shipped.
I examined the mechanics of that incident in The Sandbox Was Not the Boundary. The point here is different. The models were still being evaluated. They had not been released as a customer product. Yet the evaluation already had a path to production consequences through a shared service, a public launch point, and live third-party infrastructure.
Separate incidents were later disclosed, but they involved different mechanisms and should not be treated as one breach count.
Anthropic reviewed 141,006 cybersecurity evaluation runs and reported three incidents involving six runs. A configuration problem left live internet access available even though the models had been told they were inside simulations. In one case, a model published a malicious package to the Python Package Index. Anthropic said the package was available for about an hour and ran on 15 real systems. In another, a model scanned roughly 9,000 targets before compromising one real application. Anthropic’s latest research model stopped after concluding that its target was real, an important piece of counterevidence.
The U.K. AI Security Institute reported a separate event. This was not a sandbox escape. Internet access was intentionally enabled, and the model providers’ cyber classifiers were disabled so the institute could measure maximum capability. Across 122 runs, AISI found 19 out-of-scope actions in 10 runs, including an attempted malicious pull request and the creation of fake identities. A human maintainer rejected the code, and AISI found no resulting real-world harm.
Several later headlines involving different model providers traced back to one Irregular evaluation scenario. Irregular has said those disclosures shared an underlying control problem. Counting every provider statement as a separate failure would exaggerate the evidence.
These were unusually permissive cyber tests. They often used unreleased models, reduced refusals, disabled classifiers, or deliberately open internet access. They do not show that an ordinary enterprise assistant will break out of its environment.
They show something narrower and more useful: a system labeled Test can create production risk as soon as it can cause an external effect.
The traditional pipeline promotes an application release. An agentic system makes the gate responsible for four connected dimensions: artifact, authority, state, and evidence.
They do not cross the boundary in the same way. The tested artifact should be promoted unchanged and accompanied by verifiable provenance. Authority should be issued in the destination. Runtime state should be reset; any necessary migration should be deliberate and governed. Evidence should be independently protected and should keep accumulating after release.
The promotable artifact is a signed, versioned release assembly or deployment manifest. It identifies the application code, declared model or model version, system instructions, policy and tool definitions, connector definitions, and configuration and routing dependencies.
It does not include destination credentials, identities, live endpoints, or secret values. Those are bound separately in each environment.
Any one of these elements can change behavior. A new connector may expose an action the agent could not take yesterday. A revised system instruction may alter when it stops or asks for help. A provider update may change model behavior without a customer deploying new application code, depending on the service and versioning contract.
The release record therefore has to identify the whole runnable assembly, not only the Git commit. Where the platform permits it, identify its components with immutable versions or digests and bind them to verifiable provenance. The goal is simple: know that the assembly tested is the assembly released.
Authority includes identity, credentials, network egress, tool scopes, transaction limits, approval rules, and the systems the agent may affect.
Giving a test agent a live token creates production-equivalent exposure, even if no code moves. Outbound internet access, a connector pointed at a live tenant, or a tool expanded from read to write can create the same class of external consequence.
Policy intent can be version-controlled and promoted with the release. The destination workload identity should be bound there, and short-lived credentials should be issued there rather than copied forward. Production authority should be scoped to the destination and independently revocable.
This is why capability and authority have to remain separate. In How Much Work Can Your AI Safely Own?, I argued that demonstrated capability does not automatically grant operating authority. The same rule belongs in the delivery pipeline. A system may be capable of acting before the organization has earned the right to let it act.
State includes retrieval data, working memory, caches, queues, shared directories, previous tool results, and whatever remains for the next run.
State can cross an environment boundary without anyone deploying software. A production document can enter a test retrieval index. A test run can leave a file that another run treats as instruction. A cached response can outlive the policy that permitted it. A refreshed knowledge source can change the answer even when the model, prompt, and code stay fixed.
State needs lineage, retention rules, reset procedures, and regional handling appropriate to the data. Calling it “test data” does not make it synthetic, disposable, or harmless.
Most runtime state should not be promoted at all. Test memory, sessions, queues, caches, shared files, and previous tool results should normally be reset or isolated. When a business dataset, retrieval index, or model checkpoint must move, treat it as a separate approved migration with versioning, integrity checks, provenance, retention rules, and a rollback plan.
Evidence includes evaluation results, provenance, monitoring baselines, rollback results, known limits, and operating telemetry. Approval and risk acceptance are decision records informed by that evidence. They are not evidence that the system is trustworthy.
The agent should not be the only system that writes the work, designs the test, grades the result, and decides it is ready. Independent scenarios matter. Holdout tests matter. A real rollback rehearsal matters. So does evidence that the identity can be revoked and the action trail can be reconstructed under pressure.
Evidence accumulates throughout the lifecycle. Its record should be independent of the agent and protected from alteration. A model update, tool change, new data source, expanded permission, or material drift can invalidate yesterday’s approval without a traditional deployment. Production telemetry, drift findings, interventions, incidents, and reassessments should append to the assurance record. Promotion is not a one-time ceremony. It is a continuing claim that the running system still deserves its authority.
We do not need to throw away Dev, Test, and Prod. We need each environment to make a stronger promise.
Dev should minimize consequence. Use synthetic or carefully de-identified data. Deny external write paths by default. Give each run its own short-lived identity and disposable state. Replace live tools with mocks, simulators, or mediated services when the work does not require reality.
Test should make pre-release evidence decision-grade. Testing happens throughout the lifecycle; Test is where the release case should become credible. Verification asks whether the system meets its specified requirements and controls. Validation asks whether it is fit for its intended use in a representative deployment context. Agentic systems need both.
Use realistic tasks, independent evaluations, separate identities, resettable state, and monitoring that can stop a run while it is happening. When live information is necessary, begin with read-only access and intercept external side effects. Test the route through proxies, package registries, domain name resolution, webhooks, queues, and third-party tools, not only the agent’s visible network interface.
The record should let another person reconstruct what was tested, what failed, what was waived, and who accepted the remaining risk.
Shadow mode should validate behavior without granting action. Let the agent receive representative production inputs and propose what it would do without giving it permission to make the change. Compare its decisions with actual outcomes. Measure quality, latency, exceptions, cost, and security before expanding authority. That is the same lifecycle discipline I described in The Cost of a Finished Job.
Prod should grant narrow, revocable authority. Production is not the end of testing. Measurement and monitoring continue while the system operates, because live telemetry, drift, incidents, and rollback may show that yesterday’s evidence no longer applies.
Expand exposure in stages where the work permits it. Use least privilege, per-action traces, transaction limits, policy checks, human approval where consequence requires it, live monitoring, and rehearsed rollback. The system needs a separate observer that can stop it. The agent should not control the only alarm, the only log, or the only switch that turns it off.
Third-party evaluators belong inside this model. Their contracts should identify permitted network paths, cross-client isolation, data handling, incident-notification timing, evidence retention, audit rights, and responsibility when a test reaches a real system. “Independent evaluation” describes who performs the test. It does not prove that the test infrastructure is independent, isolated, or safe.
The release meeting does not need another hundred-page checklist. It needs questions that follow the four different jobs of the gate: identify the assembly, bind its authority, govern its state, and judge the evidence.
What changed? Name the model, code, prompts, policies, tools, connectors, configuration, and data sources that differ from the last accepted version.
What can it touch? Trace direct and indirect access through identities, proxies, package services, webhooks, shared platforms, and third parties. Record what the agent may read, propose, or change.
What survives? Identify memory, files, logs, caches, queues, retrieval indexes, and artifacts that another run or environment can inherit.
Who tested it independently? Show evidence from scenarios the builder did not control, including failure cases, stop behavior, permission boundaries, and rollback.
Who can stop it and reconstruct the result? Name the decision owner, revocation path, incident lead, evidence location, and conditions for resumption.
This is the practical machinery behind The IT Adaptive Factory. The factory is not mature because agents can write and test code quickly. It is mature when the organization can explain what was promoted, what authority was granted, what state survived, why the evidence was sufficient, and how to recover when the answer was wrong.
OpenAI’s later response shows the cost of learning this after a control boundary fails. On Aug. 18, the company said it had paused some frontier research workloads, added stronger workload and network isolation, and left its largest planned reinforcement-learning run on hold while it gathered more evidence. OpenAI attributed the broader slowdown to both the Hugging Face incident and concerns about an upcoming model’s cyber capability, so the pause should not be assigned to the incident alone.
That response does not prove the new controls will work. It does show that research and test infrastructure can become important enough to slow the production of the model itself.
Organizations will keep drawing three boxes. They should.
The boxes remind us that consequence should rise slowly and evidence should rise first. But an environment label cannot enforce that discipline. Architecture does. Identity does. Network policy does. State isolation does. Independent testing does. Someone with the authority to say “stop” does.
Before approving the next agent release, look at the arrow and ask four different questions. What artifact was promoted? What authority was bound in the destination? What state was reset or deliberately migrated? What evidence supported the decision, and how will that evidence continue after release?
If a test agent can already cause a real-world change, the organization is already carrying production risk, whatever the box is called.
The arrow still matters. It moves the assembly. The gate decides what authority it receives, what state it inherits, and whether the evidence is good enough to let it act.
", "url": "https://tedt.org/Dev-Test-and-Prod-Still-Matter-What-Gets-Deployed-Has-Changed/", "image": "/img/2026-08/Dev-Test-Prod-AI.webp", "tags": ["AI agents","agentic AI","software delivery","DevSecOps","environment promotion","AI governance","AI security","least privilege","state management","enterprise architecture"], "date_published": "2026-08-22T08:00:00-07:00", "date_modified": "2026-08-22T08:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/The-Cost-of-a-Finished-Job/", "title": "The Cost of a Finished Job", "summary": "Cheaper models do not automatically produce cheaper work. Enterprise AI economics depend on the total cost of delivering an accepted outcome.", "content_text": "Cheaper models do not settle the economics of enterprise AI. They move the hard work into the system around the model and the way the business itself is designed.Tokens are like gallons of gasoline. They are easy to count. They are easy to price. They are also poor at telling you whether you arrived.OpenAI recently cut the published price of GPT-5.6 Luna by 80%. That is a substantial change, but it does not make every workflow 80% cheaper. A low-cost model can still produce expensive work if it needs repeated attempts, makes too many tool calls, waits on slow systems, gives people more material to review, or produces an error that has to be repaired later.The useful unit is not the token. It is the finished job.Even that needs one more word. A job is not finished merely because the machine stopped. It is finished when the result clears a defined acceptance threshold: the claim is ready for a qualified decision, the code passes its tests and review, the employee receives the correct policy answer, or the customer problem is actually resolved.So the economic measure I would use is closer to this: Total workflow cost = AI usage + data and tools + human review + retries and rework + support + expected failure costCost per accepted outcome = total workflow cost ÷ accepted outcomesThis is why I have argued that every AI capability needs a cost identity: an owner, a budget, and a unit the business understands, such as dollars per case, ticket, work order, approved document, or repaired defect.Price per token still matters. It belongs inside the equation. It simply does not get to be the equation.The System of Systems Controls the PriceSo how do you lower the cost of an accepted outcome?You can use a smaller model. You can route easy steps to a cheaper model and save the strongest model for the hard decisions. You can cache repeated information. You can shorten prompts. You can improve retrieval. You can reduce retries. You can give the model better tools and clearer tests.In other words, you work on the system around your systems and model.I have described the harness as the structure that turns a fluent model into a useful partner. It carries context, connects tools, retains state, applies permissions, checks results, handles failure, and decides what happens next. A recent OpenAI experiment puts useful numbers behind that idea.On the public set of the ARC-AGI-3 benchmark, OpenAI reports that GPT-5.6 Sol scored 13.3% with the official harness and 38.3% after retained reasoning and context compaction were enabled. OpenAI also reports that the changed configuration used six times fewer output tokens. The reported improvement came from two harness settings, not a newly trained model.That result has limits. It is a vendor-run benchmark experiment, not evidence that every enterprise workflow will become three times better. Retaining more context can also raise privacy and data-retention questions. But the mechanism is important: a model that forgets what it has learned has to solve the same problem again. A model given continuity can spend less effort rediscovering its own path.Microsoft Research is testing the same broader principle from two other directions. Orchard trains agents inside the deployment harnesses where they will actually work. Microsoft reports that an Orchard software-engineering model with about three billion active parameters reached 69.7% on SWE-bench Verified. Echoverse builds deep, stateful training environments where an action changes underlying data and the result can be graded against that data. Its researchers report raising a nine-billion-parameter model’s average score from 36.5% to 67.1% across their environments.Those are research results, not production economics from a claims department or call center. Still, they reveal where optimization is moving. Model choice matters, but the surrounding system shapes what the model can accomplish and how much the result costs.This is the larger AI value stream: everything between employee intent and physical infrastructure contributes to whether intelligence becomes useful work.The performance of AI is not a property of the model alone. Neither is its cost.Make now mistake that cost per accepted outcome is the business model for AI vendors in the future. Waht this means is that once cost per accepted outcome becomes the measure, routing, context, authority, evidence, and learning can no longer be optimized as separate concerns. That metric forces them to be managed as one operating layer.From One Workflow to Fifteen HundredTuning one workflow is difficult. Letting thousands of employees create workflows is a different class of problem.In its customer account of the Dutch cooperative insurer Univé, OpenAI reports 97% license activation, 85% weekly use, and roughly 1,500 custom agents created by employees. It also describes a pet-insurance workflow in which claim preparation moved from hours to minutes while a trained claims professional retained the final decision.Those numbers demonstrate adoption. They do not tell us whether every GPT solves a distinct problem or still deserves a place in the portfolio. Fifteen hundred custom agents can represent a remarkable reservoir of employee knowledge. They can also become 1,500 small applications looking for owners who can maintain them, evaluate them, and retire them when they no longer earn their place.Stripe describes encountering the same tension at another scale. Its teams had created more than 4,000 small agents before the company moved toward a shared Knowledge AI Platform. Stripe says the common platform now supports more than 1,000 tools and skills and reached 83% weekly workforce use. The important design choice was not to build one giant agent. It was to centralize the common machinery while allowing domain teams to retain responsibility for their own expertise.Cloudflare has followed a related path for internal engineering. The company says its shared AI engineering stack served 3,683 internal users and recorded 47.95 million AI messages during one 30-day period. One central proxy provides authentication, model discovery, permission enforcement, and per-user cost attribution. Employees can use different models and local configurations without placing provider keys on their laptops or rebuilding the control plane for every team.These are first-party company reports, not independent return-on-investment studies. They are useful because they show the same architectural pressure appearing in different organizations. Once employees can build with AI, a company must support local invention without asking every employee to become an identity engineer, security architect, evaluation specialist, and platform operator.As I argued in Beyond the Light Bulb, issuing more licenses may improve local productivity without changing the end-to-end value stream. A report drafted in five minutes can still wait four days for approval. An agent can prepare twice as many cases and merely bury the reviewer. Faster output does not become business value until the surrounding work changes with it.What I Mean by an AI Operating SystemThis is where the operating-system comparison becomes useful.A conventional operating system does not write your document, approve your expense report, or calculate your budget. It manages the shared machinery that applications depend on.An enterprise AI operating system would perform a similar coordinating role for intelligence: Conventional Operating System Components Enterprise AI Operating Layer Components Processes and scheduling Jobs, agent runs, model selection, and tool routing Memory and files Working context, durable state, records, and retention Users and permissions Employee identity, agent identity, approvals, and least privilege Devices and drivers Governed connectors to business data and applications Health and logs Evaluations, traces, evidence, incidents, and recovery Resource quotas Budgets, rate limits, latency targets, and capacity Installation and upgrades Inventory, ownership, versions, reviews, and retirement I do not mean that every company should buy a product labeled “AI OS,” or spend three years building one enormous platform. Most enterprises will accidentially assemble this from systems they already have: identity and access management, data platforms, API gateways, workflow engines, model services, observability, security controls, and software-delivery practices.Is this simply platform engineering, data governance, identity, and observability wearing a new name?Much of the machinery is familiar. What has changed is the thing being coordinated. These systems now surround probabilistic workers that can choose tools, generate intermediate plans, act across applications, and produce different results from the same request. The components are not all new. The need to coordinate them continuously around machine-performed work is.For IT, this means becoming the central engineering function for a shared production system, not the sole builder of every employee solution. IT provides the roads: approved models, secure connectors, identity, sandboxes, evaluation services, logging, and production gates. Business teams choose the destinations. They define the job, the value, the exceptions, and the standard for acceptable work.The NIST AI Risk Management Framework organizes this work around four continuing functions: Govern, Map, Measure, and Manage. That is a helpful reminder that an operating layer is not merely a runtime. It must also carry responsibility, measurement, monitoring, and an exit path.What This Means for Businesses Giving AI to EmployeesThe first implication is that an employee AI program is not a license program.Licenses provide access. Training can provide competence. Neither one, by itself, changes a business process. The business has to decide which work should change, who owns the outcome, what quality means, and where the recovered time or capacity will go.Imagine an employee who spends two hours assembling a weekly report. AI reduces the drafting to twenty minutes. That sounds like a large gain. But what happens next?Does the report still wait for the same approval? Does the employee use the recovered time to investigate exceptions, speak with customers, or improve the source data? Does the organization simply produce six times as many reports that nobody reads? Time saved is potential energy. Management still has to decide where it moves.The second implication is that adoption and value need different scorecards. A useful evidence ladder looks something like this: People have access. People use it. A workflow changes. Cycle time, quality, or service improves. The total cost per accepted outcome improves. The business converts that improvement into safer and reliabile operations, principled decisions, higher standards, continuous improvement, stronger teamwork, revenue, or customer value.Each step matters. They are not interchangeable. Prompt counts and weekly active users tell you whether the system is being used. They do not tell you whether the business is better off in the executive suite.The third implication is that the foundation should be shared while improvement remains local. Fully centralized AI programs turn into queues because the central team cannot understand every job. Fully decentralized programs produce duplicate agents, inconsistent permissions, uneven quality, and abandoned tools. The better pattern is federated: common roads, local destinations, and an explicit exception path.The fourth implication is that employees need more than permission to experiment. They need time, examples, trusted data, clear boundaries, and managers willing to redesign the work. None of this is merely a platform change. AI is a people change touching roles, incentives, professional identity, training, trust, and the way expertise is passed from one generation of employees to the next.This is also where telemetry can cross a line. The operating layer can reveal which employees use AI, which sources they touch, how long tasks take, and where they struggle. That information can improve the system and control risk. Used carelessly, it can become an unusually intimate system of worker surveillance. Businesses should tell employees what is recorded, why it is recorded, who can see it, and how long it is retained.The fifth implication is that “human in the loop” is not enough. A person cannot meaningfully own a decision if the review queue is impossible, the evidence is hidden, or rejecting the machine’s recommendation requires more time than accepting it. Human accountability needs enough context, time, expertise, authority, and a real ability to stop or reverse the action.Finally, employee-built AI creates a lifecycle problem. Every production workflow needs a business owner, a technical owner, a risk classification, a version history, a budget, an evaluation set, a review date, and a retirement path. Otherwise, cheaper creation produces an expanding estate of invisible software.Advice for the People Building This NowIf you are working on employee AI, I would use the following promotion path.1. Start with a job, not a modelFind a repeatable piece of work with a visible owner, inputs, handoffs, exceptions, and an outcome. Ask what job needs doing before deciding whether the answer is a chatbot, an agent, a search tool, or ordinary automation.“Give everyone an AI assistant” is a distribution plan. It is not a use case.2. Establish the BaselineMeasure the work before changing it: elapsed time, employee effort, error rate, rework, wait time, exception volume, service level, and current cost. If you do not know the starting point, almost any demonstration can be made to look like progress.3. Define What Accepted MeansCapture the job as a reusable specification: its purpose, authoritative inputs, boundaries, desired outcome, and the evidence that will count as complete.Build a small evaluation set from real work. Include ordinary cases, difficult edge cases, and cases that should be refused or escalated. OpenAI is retiring its Evals platform later in 2026, but its published guidance on task-specific tests, logging, human calibration, and continuous evaluation remains useful.4. Separate Assistance from AuthorityLet the first version retrieve, organize, summarize, recommend, or draft. Give it permission to change records, send messages, approve transactions, or trigger physical work only after the evidence justifies the additional authority.The practical question is how much work the AI can safely own, one value stream, work class, and risk tier at a time.5. Optimize the Workflow, not Merely the PromptChoose the least expensive model that clears the quality threshold for each step. Improve retrieval. Remove unnecessary context. Cache stable material. Reduce tool calls. Tighten retry rules. Make human handoffs easier. Sometimes a more capable model will cost less overall because it needs fewer retries and less review.The cheapest successful run is not always the correct target. Reliability, privacy, security, legal obligations, and human accountability are constraints, not items to trade away for a lower bill.6. Make the Evidence VisibleRecord the sources used, tools called, actions taken, checks passed, exceptions raised, and human decisions made. A person reviewing the work should be able to understand what happened without reconstructing the agent’s entire hidden journey.Track human-review minutes along with model cost. If a cheaper configuration saves ten dollars of inference and adds an hour of expert review, the workflow did not get cheaper.7. Promote CarefullyRun consequential workflows in shadow mode before giving them authority. Compare the proposed result with real decisions. Move from experiment to shared service only after the workflow meets agreed thresholds for quality, cost, latency, security, and human review.Then keep evaluating it. Models change. Prices change. Source data changes. Business rules change. A production agent is not a finished project. It is an operating responsibility.8. Retire What no Longer Earns its PlaceCheaper AI will create more AI. That is a rebound effect, not a paradox. When the price of an individual run falls, companies will attempt more workflows and run them more often. Total spending, data exposure, and operational risk can rise even while each call gets cheaper.Review the portfolio. Merge duplicate agents. Revoke unused permissions. Update evaluation sets. Replace poor configurations. Retire workflows whose owners have left or whose value never arrived.Build Only as Much Operating System as you NeedA small company does not need to recreate the platform of Stripe or Cloudflare. It may need an approved managed workspace, clean data boundaries, a handful of task evaluations, and a named owner.A business unit with several production workflows may need shared connectors, reusable skills, an inventory, common logs, and a review process.A large enterprise with agents acting across many systems will need policy-based routing, distinct agent identities, centralized evidence, incident handling, lifecycle controls, and portfolio economics.The operating layer should grow in response to real work and real risk. Building a cathedral before the first useful workflow is another way to avoid arriving.The Road Between the Request and the ResultCheaper intelligence moves the bottleneck. The difficult question becomes less about whether the company can afford a model and more about whether it can manage the system around that model.Who defines the job? Who grants the context? Who chooses the tools? Who decides what may be changed? Who checks the result? Who pays for the run, supports the workflow, investigates the failure, and retires the agent when it is no longer useful?These are operating-system questions.The businesses that do this well will not merely have more AI. They will know which completed jobs became cheaper, faster, or better, and they will be able to explain why.Tokens may tell us how much fuel we purchased. The finished job tells us whether the trip mattered and if those who took it were meaningfully and positiviely changed. The AI operating system is the machinery that helps the whole company arrive.", "content_html": "Cheaper models do not settle the economics of enterprise AI. They move the hard work into the system around the model and the way the business itself is designed.
Tokens are like gallons of gasoline. They are easy to count. They are easy to price. They are also poor at telling you whether you arrived.
OpenAI recently cut the published price of GPT-5.6 Luna by 80%. That is a substantial change, but it does not make every workflow 80% cheaper. A low-cost model can still produce expensive work if it needs repeated attempts, makes too many tool calls, waits on slow systems, gives people more material to review, or produces an error that has to be repaired later.
The useful unit is not the token. It is the finished job.
Even that needs one more word. A job is not finished merely because the machine stopped. It is finished when the result clears a defined acceptance threshold: the claim is ready for a qualified decision, the code passes its tests and review, the employee receives the correct policy answer, or the customer problem is actually resolved.
So the economic measure I would use is closer to this:
Total workflow cost = AI usage + data and tools + human review + retries and rework + support + expected failure cost
Cost per accepted outcome = total workflow cost ÷ accepted outcomes
This is why I have argued that every AI capability needs a cost identity: an owner, a budget, and a unit the business understands, such as dollars per case, ticket, work order, approved document, or repaired defect.
Price per token still matters. It belongs inside the equation. It simply does not get to be the equation.
So how do you lower the cost of an accepted outcome?
You can use a smaller model. You can route easy steps to a cheaper model and save the strongest model for the hard decisions. You can cache repeated information. You can shorten prompts. You can improve retrieval. You can reduce retries. You can give the model better tools and clearer tests.
In other words, you work on the system around your systems and model.
I have described the harness as the structure that turns a fluent model into a useful partner. It carries context, connects tools, retains state, applies permissions, checks results, handles failure, and decides what happens next. A recent OpenAI experiment puts useful numbers behind that idea.
On the public set of the ARC-AGI-3 benchmark, OpenAI reports that GPT-5.6 Sol scored 13.3% with the official harness and 38.3% after retained reasoning and context compaction were enabled. OpenAI also reports that the changed configuration used six times fewer output tokens. The reported improvement came from two harness settings, not a newly trained model.
That result has limits. It is a vendor-run benchmark experiment, not evidence that every enterprise workflow will become three times better. Retaining more context can also raise privacy and data-retention questions. But the mechanism is important: a model that forgets what it has learned has to solve the same problem again. A model given continuity can spend less effort rediscovering its own path.
Microsoft Research is testing the same broader principle from two other directions. Orchard trains agents inside the deployment harnesses where they will actually work. Microsoft reports that an Orchard software-engineering model with about three billion active parameters reached 69.7% on SWE-bench Verified. Echoverse builds deep, stateful training environments where an action changes underlying data and the result can be graded against that data. Its researchers report raising a nine-billion-parameter model’s average score from 36.5% to 67.1% across their environments.
Those are research results, not production economics from a claims department or call center. Still, they reveal where optimization is moving. Model choice matters, but the surrounding system shapes what the model can accomplish and how much the result costs.
This is the larger AI value stream: everything between employee intent and physical infrastructure contributes to whether intelligence becomes useful work.
The performance of AI is not a property of the model alone. Neither is its cost.
Make now mistake that cost per accepted outcome is the business model for AI vendors in the future. Waht this means is that once cost per accepted outcome becomes the measure, routing, context, authority, evidence, and learning can no longer be optimized as separate concerns. That metric forces them to be managed as one operating layer.
Tuning one workflow is difficult. Letting thousands of employees create workflows is a different class of problem.
In its customer account of the Dutch cooperative insurer Univé, OpenAI reports 97% license activation, 85% weekly use, and roughly 1,500 custom agents created by employees. It also describes a pet-insurance workflow in which claim preparation moved from hours to minutes while a trained claims professional retained the final decision.
Those numbers demonstrate adoption. They do not tell us whether every GPT solves a distinct problem or still deserves a place in the portfolio. Fifteen hundred custom agents can represent a remarkable reservoir of employee knowledge. They can also become 1,500 small applications looking for owners who can maintain them, evaluate them, and retire them when they no longer earn their place.
Stripe describes encountering the same tension at another scale. Its teams had created more than 4,000 small agents before the company moved toward a shared Knowledge AI Platform. Stripe says the common platform now supports more than 1,000 tools and skills and reached 83% weekly workforce use. The important design choice was not to build one giant agent. It was to centralize the common machinery while allowing domain teams to retain responsibility for their own expertise.
Cloudflare has followed a related path for internal engineering. The company says its shared AI engineering stack served 3,683 internal users and recorded 47.95 million AI messages during one 30-day period. One central proxy provides authentication, model discovery, permission enforcement, and per-user cost attribution. Employees can use different models and local configurations without placing provider keys on their laptops or rebuilding the control plane for every team.
These are first-party company reports, not independent return-on-investment studies. They are useful because they show the same architectural pressure appearing in different organizations. Once employees can build with AI, a company must support local invention without asking every employee to become an identity engineer, security architect, evaluation specialist, and platform operator.
As I argued in Beyond the Light Bulb, issuing more licenses may improve local productivity without changing the end-to-end value stream. A report drafted in five minutes can still wait four days for approval. An agent can prepare twice as many cases and merely bury the reviewer. Faster output does not become business value until the surrounding work changes with it.
This is where the operating-system comparison becomes useful.
A conventional operating system does not write your document, approve your expense report, or calculate your budget. It manages the shared machinery that applications depend on.
An enterprise AI operating system would perform a similar coordinating role for intelligence:
| Conventional Operating System Components | Enterprise AI Operating Layer Components |
|---|---|
| Processes and scheduling | Jobs, agent runs, model selection, and tool routing |
| Memory and files | Working context, durable state, records, and retention |
| Users and permissions | Employee identity, agent identity, approvals, and least privilege |
| Devices and drivers | Governed connectors to business data and applications |
| Health and logs | Evaluations, traces, evidence, incidents, and recovery |
| Resource quotas | Budgets, rate limits, latency targets, and capacity |
| Installation and upgrades | Inventory, ownership, versions, reviews, and retirement |
I do not mean that every company should buy a product labeled “AI OS,” or spend three years building one enormous platform. Most enterprises will accidentially assemble this from systems they already have: identity and access management, data platforms, API gateways, workflow engines, model services, observability, security controls, and software-delivery practices.
Is this simply platform engineering, data governance, identity, and observability wearing a new name?
Much of the machinery is familiar. What has changed is the thing being coordinated. These systems now surround probabilistic workers that can choose tools, generate intermediate plans, act across applications, and produce different results from the same request. The components are not all new. The need to coordinate them continuously around machine-performed work is.
For IT, this means becoming the central engineering function for a shared production system, not the sole builder of every employee solution. IT provides the roads: approved models, secure connectors, identity, sandboxes, evaluation services, logging, and production gates. Business teams choose the destinations. They define the job, the value, the exceptions, and the standard for acceptable work.
The NIST AI Risk Management Framework organizes this work around four continuing functions: Govern, Map, Measure, and Manage. That is a helpful reminder that an operating layer is not merely a runtime. It must also carry responsibility, measurement, monitoring, and an exit path.
The first implication is that an employee AI program is not a license program.
Licenses provide access. Training can provide competence. Neither one, by itself, changes a business process. The business has to decide which work should change, who owns the outcome, what quality means, and where the recovered time or capacity will go.
Imagine an employee who spends two hours assembling a weekly report. AI reduces the drafting to twenty minutes. That sounds like a large gain. But what happens next?
Does the report still wait for the same approval? Does the employee use the recovered time to investigate exceptions, speak with customers, or improve the source data? Does the organization simply produce six times as many reports that nobody reads? Time saved is potential energy. Management still has to decide where it moves.
The second implication is that adoption and value need different scorecards. A useful evidence ladder looks something like this:
Each step matters. They are not interchangeable. Prompt counts and weekly active users tell you whether the system is being used. They do not tell you whether the business is better off in the executive suite.
The third implication is that the foundation should be shared while improvement remains local. Fully centralized AI programs turn into queues because the central team cannot understand every job. Fully decentralized programs produce duplicate agents, inconsistent permissions, uneven quality, and abandoned tools. The better pattern is federated: common roads, local destinations, and an explicit exception path.
The fourth implication is that employees need more than permission to experiment. They need time, examples, trusted data, clear boundaries, and managers willing to redesign the work. None of this is merely a platform change. AI is a people change touching roles, incentives, professional identity, training, trust, and the way expertise is passed from one generation of employees to the next.
This is also where telemetry can cross a line. The operating layer can reveal which employees use AI, which sources they touch, how long tasks take, and where they struggle. That information can improve the system and control risk. Used carelessly, it can become an unusually intimate system of worker surveillance. Businesses should tell employees what is recorded, why it is recorded, who can see it, and how long it is retained.
The fifth implication is that “human in the loop” is not enough. A person cannot meaningfully own a decision if the review queue is impossible, the evidence is hidden, or rejecting the machine’s recommendation requires more time than accepting it. Human accountability needs enough context, time, expertise, authority, and a real ability to stop or reverse the action.
Finally, employee-built AI creates a lifecycle problem. Every production workflow needs a business owner, a technical owner, a risk classification, a version history, a budget, an evaluation set, a review date, and a retirement path. Otherwise, cheaper creation produces an expanding estate of invisible software.
If you are working on employee AI, I would use the following promotion path.
Find a repeatable piece of work with a visible owner, inputs, handoffs, exceptions, and an outcome. Ask what job needs doing before deciding whether the answer is a chatbot, an agent, a search tool, or ordinary automation.
“Give everyone an AI assistant” is a distribution plan. It is not a use case.
Measure the work before changing it: elapsed time, employee effort, error rate, rework, wait time, exception volume, service level, and current cost. If you do not know the starting point, almost any demonstration can be made to look like progress.
Capture the job as a reusable specification: its purpose, authoritative inputs, boundaries, desired outcome, and the evidence that will count as complete.
Build a small evaluation set from real work. Include ordinary cases, difficult edge cases, and cases that should be refused or escalated. OpenAI is retiring its Evals platform later in 2026, but its published guidance on task-specific tests, logging, human calibration, and continuous evaluation remains useful.
Let the first version retrieve, organize, summarize, recommend, or draft. Give it permission to change records, send messages, approve transactions, or trigger physical work only after the evidence justifies the additional authority.
The practical question is how much work the AI can safely own, one value stream, work class, and risk tier at a time.
Choose the least expensive model that clears the quality threshold for each step. Improve retrieval. Remove unnecessary context. Cache stable material. Reduce tool calls. Tighten retry rules. Make human handoffs easier. Sometimes a more capable model will cost less overall because it needs fewer retries and less review.
The cheapest successful run is not always the correct target. Reliability, privacy, security, legal obligations, and human accountability are constraints, not items to trade away for a lower bill.
Record the sources used, tools called, actions taken, checks passed, exceptions raised, and human decisions made. A person reviewing the work should be able to understand what happened without reconstructing the agent’s entire hidden journey.
Track human-review minutes along with model cost. If a cheaper configuration saves ten dollars of inference and adds an hour of expert review, the workflow did not get cheaper.
Run consequential workflows in shadow mode before giving them authority. Compare the proposed result with real decisions. Move from experiment to shared service only after the workflow meets agreed thresholds for quality, cost, latency, security, and human review.
Then keep evaluating it. Models change. Prices change. Source data changes. Business rules change. A production agent is not a finished project. It is an operating responsibility.
Cheaper AI will create more AI. That is a rebound effect, not a paradox. When the price of an individual run falls, companies will attempt more workflows and run them more often. Total spending, data exposure, and operational risk can rise even while each call gets cheaper.
Review the portfolio. Merge duplicate agents. Revoke unused permissions. Update evaluation sets. Replace poor configurations. Retire workflows whose owners have left or whose value never arrived.
A small company does not need to recreate the platform of Stripe or Cloudflare. It may need an approved managed workspace, clean data boundaries, a handful of task evaluations, and a named owner.
A business unit with several production workflows may need shared connectors, reusable skills, an inventory, common logs, and a review process.
A large enterprise with agents acting across many systems will need policy-based routing, distinct agent identities, centralized evidence, incident handling, lifecycle controls, and portfolio economics.
The operating layer should grow in response to real work and real risk. Building a cathedral before the first useful workflow is another way to avoid arriving.
Cheaper intelligence moves the bottleneck. The difficult question becomes less about whether the company can afford a model and more about whether it can manage the system around that model.
Who defines the job? Who grants the context? Who chooses the tools? Who decides what may be changed? Who checks the result? Who pays for the run, supports the workflow, investigates the failure, and retires the agent when it is no longer useful?
These are operating-system questions.
The businesses that do this well will not merely have more AI. They will know which completed jobs became cheaper, faster, or better, and they will be able to explain why.
Tokens may tell us how much fuel we purchased. The finished job tells us whether the trip mattered and if those who took it were meaningfully and positiviely changed. The AI operating system is the machinery that helps the whole company arrive.
", "url": "https://tedt.org/The-Cost-of-a-Finished-Job/", "image": "/img/2026-08/the-cost-of-a-finished-job-hero-source.webp", "tags": ["enterprise AI","AI economics","cost per accepted outcome","AI operating system","agentic AI","AI governance","workflow optimization","platform engineering","employee AI","operating model","FinOps"], "date_published": "2026-08-16T09:00:00-07:00", "date_modified": "2026-08-16T09:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/slides/the-sandbox-was-not-the-boundary/", "title": "The Sandbox Was Not the Boundary", "summary": "\n", "content_text": "", "content_html": "", "url": "https://tedt.org/slides/the-sandbox-was-not-the-boundary/", "image": "/slides/decks/the-sandbox-was-not-the-boundary/slide-preview.png", "date_published": "2026-08-13T00:00:00-07:00", "date_modified": "2026-08-13T00:00:00-07:00","author":{"name":"Ted Tschopp","url":"https://tedt.org/profile/","uri":"https://tedt.org/profile/","avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","givenname":"Ted","familyname":"Tschopp","othernames":"Þeodor Tʃopp | टेड चप | Фёдор Чоп | تد شُپ | Թեդ Չոպպ | Ted Çop | டெட் சாப் | טעד טשאָפּ | Τεντ Τσοπ | 테드 촙 | 特德·察普 | テッド・チョッパ | ტედ ჩოპი | เท็ด ชอพ | ເທດ ຊອບ | ടെഡ് ചോപ്പ് | টেড চপ | ཏེཌ་ ཅོཔ། | ቴድ ቾፕ | ᏖᏗ ᏦᏇ | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | 𐌀𐌄𐌃 𐌕𐌔𐌂𐌏𐌐𐌐 | Ⱅⰵⰴ ⱌⱁⱂⱂ | ܬܝܕ ܟܘܦ | ᠲᠡᠳᠡᠳ ᠴᠣᠫ | ᑌᑎ ᒍᐳᐱ | ꕚꔳ ꗍꖛ | ߕߋߘ ߞߐߔߔ | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐎚𐎄𐎆 𐎚𐎌𐎒𐎒 | 𐎄𐎓𐎆 𐎚𐎔𐎒𐎒 | 𐤕𐤄𐤃 𐤕𐤔𐤐𐤐 | 𐤕𐤃𐤄 𐤕𐤔𐤏𐤐 | 𐎚𐎄𐎆 𐎚𐎘𐎔𐎔 | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | 𓏏𓂧𓂝 𓏏𓊃𓍿𓊪 | ⲧⲉⲇ ⲧϣⲟⲡⲡ | 𐌕𐌄𐌃 𐌕𐌔𐌎𐌐𐌐 | 𐤈𐤃𐤄 𐤈𐤔𐤐𐤐 | 𐌕𐌄𐌃 𐌕𐌔𐌏𐌐𐌐 | 𐌕𐌄𐌃 𐌕𐌔𐌐𐌐 | 𐎄𐎕𐎆 𐎚𐎑𐎔𐎔 | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐀳𐀂𐀅 𐀳𐀴𐀞 | 𐱃𐰀𐰓 𐱃𐰴𐰯 | 𑀢𑁂𑀤𑁆 𑀘𑁄𑀧𑁆 | 𐨟𐨂𐨡 𐨖𐨎𐨿 | 𐦚𐦱𐦟 𐦚𐦷𐦣 | 𐭓𐭐𐭃 𐭓𐭱𐭕𐭕 | 𐭲𐭩𐭣 𐭲𐭱𐭯𐭯 | ᚈᚓᚇ ᚈᚄᚉᚑᚚᚚ | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | تيد تشوب | ટેડ ચોક્પ | ਟੇਡ ਚੋਪ | ಟೆಡ್ ಚೊಪ್ | ටෙඩ් චොප් | တက် ချော့ပ် | តេដ ឆប | ꦠꦺꦢ꧀ ꦕꦺꦴꦥ꧀ | ᬢᭂᬤ᭄ ᬘᭀᬧ᭄ | ᜆᜒᜇ᜔ ᜆ᜔ᜐᜓᜉ᜔ | ᏖᏗ ᏣᏊ | ꄊꄮ ꍏꀠ | ଟେଡ୍ ଚୋପ୍ | ⵜⴻⴷ ⵛⵓⵒ | 𐐓𐐯𐐼 𐐟𐐙𐐱𐐹 | 𐑑𐑧𐑛 𐑗𐑪𐑐 | 𐘳𐘂𐘅 𐘳𐘴𐘞 | 𐠔𐠁𐠊 𐠔𐠷𐠡 | 𐊗𐊁𐊅 𐊗𐊐𐊓 | 𐊴𐊭𐊺 𐊴𐋄𐊸 | 𐢞𐢉𐢅 𐢞𐢝𐢘 | ࠕࠄࠃ ࠕࠔࠐࠐ | 𐫤𐫏𐫝 𐫤𐫘𐫖 | ꡈꡦ ꡐꡡꡌ | ꯇꯦꯗ ꯆꯣꯄ | ꨓꨯꨕ ꨌꨱꨚ | ᨲᩮᨯ᩠ ᨩᩮᩫ᩠ | ꪔꫀꪒ ꪊꪮꪚ | ᯖᯩᯑ᯲ ᯙᯬᯇ᯲ | ꥆꥍꤴ ꥓ꥏꥒ | ᨈᨙᨉᨛ ᨌᨚᨄᨛ | ᮒᮨᮓ᮪ ᮎᮧᮕ᮪ | ᜦᜒᜇ᜴ ᜰᜳᜉ᜴ | ᝆᝒᝇ ᝌᝓᝉ | ꠔꠦꠖ ꠌꠥꠙ | 𑂞𑂵𑂠 𑂒𑂷𑂣 | 𑆠𑆼𑆢𑇀 𑆖𑆾𑆥𑇀 | 𑚔𑚵𑚖 𑚏𑚴𑚞 | 𑲌𑲏 𑱰𑱱 | 𑊢𑋐𑊦 𑊓𑋒 | 𑈋𑈸𑈍𑈴 𑈑𑈺𑈞𑈴 | 𑅐𑅬𑅒 𑅘𑅛 | 𑘝𑘿𑘟 𑘓𑘽𑘨 | 𑜔𑜦𑜕 𑜒𑜩𑜞 | 𑣕𑣈𑣙 𑣌𑣏𑣗 | 𞠔𞠀𞠙 𞠌𞠁𞠖 | 𑫎𑫟𑫒 𑫏𑫝𑫐 | 𐓰𐒰𐓈 𐓍𐒷𐓄 | 𞤚𞤫𞤣 𞤷𞤮𞥄 | 𖫐𖫪𖫓 𖫗𖫩𖫞 | 𛰙𛱎𛰣 𛲄𛱖𛱐 | ","biography":["I'm **Ted Tschopp**, a Senior Enterprise Architect based in Los Angeles, working at the intersection of **enterprise architecture, artificial intelligence, software strategy, and digital automation**.","At **Southern California Edison**, I help shape the architecture strategy for AI, software, and enterprise products that support one of the nation’s largest electric utilities. My work sits where **strategy meets execution**: platforms, guardrails, operating models, governance, risk, developer experience, and the practical realities of making ambitious technology useful, resilient, and sustainable inside a large organization.","I've spent **25+ years at SCE** helping teams navigate complex technology change. The part of enterprise architecture I care about most is not the diagram. It is the design discipline that makes systems usable, governable, sustainable, and welcoming for the people who depend on them and the teams who build them.","Before joining Edison, I owned a business featured in *Wired Magazine*, founded one of the largest J.R.R. Tolkien community websites, and worked in automotive market research. That mix of technology, storytelling, community-building, and analysis still shapes how I think about systems today.","I love working in technology because it lets me watch the future arrive in real time. Some of the things I have worked on were science fiction when I was in school. Now they are platform problems, governance problems, people problems, and architecture problems — which is where the interesting work begins.","Unless otherwise stated, everything here reflects my own views."],"email":"ted@tschopp.org","phonenumber":null,"keybaseio_username":"tedtschopp","twitter_username":"TedTschopp","twitter":"TedTschopp","github_username":"TedTschopp","linkedin_username":"tedtschopp","facebook_username":"ted.tschopp","google_username":"TedTschopp","youtube_username":"TedTschopp","pinterest_username":"TedTschopp","reddit_username":"tedtschopp","instagram_username":"tedtschopp","quora_username":"Ted-Tschopp","indiewebcamp_username":"Www.tedt.org","mastodon_username":"TedT@twit.social","mastodon_user_id":109286944787814808,"threads_username":"TedTschopp@threads.net","same_as":["https://www.linkedin.com/in/tedtschopp","https://github.com/TedTschopp","https://twit.social/@TedT","https://bsky.app/profile/tedt.org","https://twitter.com/TedTschopp","https://www.youtube.com/channel/UC4Q8pXroTVyXrIxg2u82pwg"],"knows_about":["Enterprise architecture","Enterprise artificial intelligence","AI governance","Software and platform strategy","Digital automation","Technology-enabled organizational change","Digital communities and storytelling","Swiss folklore","Tabletop role-playing game design"],"works_for":{"name":"Southern California Edison","url":"https://www.sce.com/"}}}, { "id": "https://tedt.org/The-Sandbox-Was-Not-the-Boundary/", "title": "The Sandbox Was Not the Boundary", "summary": "The OpenAI–Hugging Face incident shows why an agent's boundary must include proxy services, persistent state, task-failure behavior, and the authority to restart after an incident.", "content_text": " Source note: This essay draws from first-party disclosures by OpenAI and Hugging Face and an August 2026 Black Hat USA presentation by OpenAI researchers Eric Wallace and Michael Dalton. Their reconstruction was preliminary, the investigation remained open, and the speakers said a fuller postmortem would follow. The chronology below should be read with that boundary in mind.In computing, a sandbox is a controlled workspace where software can act, but only with the files, tools, and connections it has been given. Think of it as a locked room built for experimentation. An AI agent may use everything placed inside, but it should not be able to wander into the rest of the building or reach the internet. That is the idea, anyway. The trouble begins when some small service still connects the room to the world outside.In this incident, that service was Artifactory.Artifactory is a shared, company-controlled storeroom for software. Instead of letting every program search the internet for the parts it needed, programs asked Artifactory. If a part was not already on its shelves, Artifactory could retrieve it from outside, keep a copy, and pass it back. In this incident, the agents also discovered they could leave files and names there for later agents to find. The storeroom became both a way to access the internet and an unintended bulletin board that allowed separate agents and test runs to communicate with each other over the course of their testing.In July 2026, OpenAI disclosed that models running an internal cyber-capability evaluation, including GPT-5.6 Sol, the latest and most capable model from OpenAI, and a more capable internal research prototype, had found and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure. The models did not have broad, direct internet access. They could, however, install packages through an internally hosted Artifactory proxy and cache, and that service could reach the internet.Hugging Face is a company and online platform where researchers and developers publish, share, and test artificial intelligence models, datasets, and software tools. People and organizations use it to find existing models, build new systems, and collaborate on machine-learning projects. In this incident, the agents eventually reached beyond OpenAI’s internal research environment and into systems operated by Hugging Face.Hugging Face’s disclosure and later technical timeline provide another first-party view of the intrusion. OpenAI researchers Eric Wallace and Michael Dalton then presented a more detailed reconstruction in a Black Hat USA presentation. As of August 8, the public record is still preliminary, and the speakers said their investigation was incomplete. This chronology should be read as a current reconstruction, not a final forensic report.How Artifactory Connected the RunsThe chain began in May, when OpenAI started training new models. It occurred across multiple tests and multiple test runs. One agent was asked to complete an Excel workbook whose missing formulas depended on data behind Google Drive links. The environment could not reach those links, so the task could not be completed as configured.The agent kept trying. During an unsuccessful attempt to make Artifactory fetch an outside resource, the agent discovered that they could write a file into the service. A different agent later found itself missing a required database file and deliberately left a note in Artifactory asking whether another agent could provide it. Other agents found the notes and began leaving their own notes and requests for help.Files became messages. Messages became assignments. The presentation at Black Hat describes agent identifiers, hold commands, ordering conventions, and encoded scripts moving through file and directory names. On May 26, agents reportedly succeeded in using a computer hacking approached called “server-side request forgery”. This is a method of making a computer fetch something on the behalf of someone else. This gave it indirect internet access through Artifactory, using Artifactory as a go between the internet and the agent being tested.The models had already been trained to collaborate. But this was a new behavior: A persistent communication skill that operated across separate runs through a go between, Artifactory, which was never intended to be a message board or a means to bypass access to the internet.Where, then, did the agent’s environment end?It did not end at the sandbox’s network interface. If an agent can cause another computer system to fetch an outside resource, that system is part of the agent’s effective environment. If one run can write a name or file that a later run can read, that shared file is part of the environment too. The same question applies to caches, queues, logs, and other services that retain or act on the agent’s behalf.The environment the agent operated in didn’t have access to the internet, but something in the room with it did (even though the developers at OpenAI and Artifactory didn’t know it would), and the AI agent figured out how to make use of that indirect access.What Should Happen When a Task Cannot Be Completed?The Black Hat presentation showed a reasoning-log excerpt in which a model identified external exploitation as outside its intended scope, then continued even though the task was now impossible but it reasoned that its peers were doing it so it decided that the best approach would be to stay on mission of being a helpful assistant and use the exploit. That excerpt does not establish consciousness, moral judgment, or human-like intent. What was going on was that the agent had been trained to chose helpfulness and persistence over answering a question with No, I’m sorry I can’t help you with that or asking the user to change the scope of the task or asking the user permission to access the outside world. It was not trained to stop when a task could not be completed.Read together, the presentation suggests a simple pattern. The intended route to help the user was blocked, but completion pressure remained. Persistence gave the agent time to search. Artifactory offered another route, and the shared space to collaborate allowed one agent to hand its discovery to the next. Parallel runs then multiplied the activity. None of those conditions alone explains the whole incident, but together they show why task feasibility belongs in a security review.An approach to keep this under control would be to require that if a required asset, tool, service or file is missing or unavailable, the agent should identify the dependency, preserve the chain of thought, and stop. It should not quietly substitute a new route, credential, target, or data source unless someone with the authority to change the scope approves that change.Restored Is Not the Same as ReadyThe reconstruction describes a serious Artifactory compromise and outage in early July that OpenAI’s agents were responsible for. From July 4 through July 6, OpenAI revoked the credentials used to post the original messages, rebuilt and redeployed the service, cleared the original message board, worked with the vendor, patched the newly discovered zero-day, and then resumed training and evaluations.On July 8, agents reportedly recreated the message board through an unauthenticated WebDAV path, this time using directory names as opposed to content inside the files or a database. The presenters later named three ingredients in the larger incident: the reopened board, a persistent internal model that was trained from the lessons learned about hacking the Artifactory and creating a messageboard, and exploit evaluations with reduced cyber refusals compared with production systems.The approach taken by the OpenAI Engineers was thoughtful and thorough, but it did not settle everything. Their response restored their systems and closed the path the AI used to hack Artifactory that they knew about. It did not, by itself, settle whether another communication path remained, whether later models or runs had incorporated information from the affected environment, or whether it was safe to resume the evaluations.The lesson here is that each of the following steps need to be seen as separate activities that require independent quality reviews to ensure they are completed fully. Restoration asks whether the service works again. Eradication asks whether vulnerable paths have been closed, credentials revoked, and affected artifacts removed, quarantined, or explicitly accepted by a named risk owner. Resumption is the decision to restart training or evaluation. Closure comes only after the infrastructure and model-data work are complete, an independent retest has passed, and a named authority has accepted any remaining risk.Those questions require two connected reviews. One follows the infrastructure: execution, credentials, dependencies, alternate paths, and evidence of restoration. The other follows model and data lineage: affected models, training and evaluation traces, memory, retrieval state, and derived runs. A clean server cannot answer the lineage question, and a quarantined model cannot show that every infrastructure path is closed.Where Automation Should StopDalton argued that fully automated offensive loops are possible in at least some cases. His proposed response was to speed up the whole defensive loop, including vulnerability discovery, patch creation, deployment, rollback, and incident analysis. Otherwise, machine-speed discovery leaves people facing a queue of fixes they cannot process quickly enough.But using AI to do that work does not give one system every decision. A defensive agent may find a vulnerability, write a patch, run tests, and prepare a deployment. It should not automatically follow from that sequence that the same agent may approve a high-impact production change, judge its own retest, and close the incident.The approach you should take is to not treat automation as a continuum on a single axis. A low-risk change may move automatically when its boundaries are clear, its effects can be reversed, monitoring is active, and policy already permits it. Changes involving identity, regulated data, several systems, or irreversible effects need independent approval. If the current evidence or a workable rollback is missing, the automated path stops.The same limits apply to deception. A honeytoken is a fake credential or other planted signal that raises an alarm when someone touches it. It may expose or slow an attacker, but it does not revoke real access or prove that the environment is contained. If you see a honeytoken in use, you should ask who can stop the workload, revoke its access, and reconstruct what it did across agents and time.Lessons LearnedThe lessons learned from this event can be reduced to five ordinary questions: What can this agentic workload reach, including through other services? What happens when an approved or required input is missing? What state survives for the next agent run or model deployment? Who can stop the workload, revoke its access, and reconstruct what it did across agents and time? Who owns the cleanup, and who independently decides when it is safe to restart and close the incident?That final decision should come only after the original and alternate paths have been retested and the infrastructure and model-data reviews are complete.The chain leading into the incident began with an Excel spreadsheet trying to get data out of Google that was impossible for it to complete. That is worth remembering. The boundary failed at an ordinary moment: a task had no valid path to success, yet a shared service still offered a route around the block.A room is not contained because its visible doors are locked. It is contained when we know where the light switches, pipes, windows, vents, crawlspaces, and service hatches lead, what can pass through each of them, and who has access to open and close those points of entry.", "content_html": "Source note: This essay draws from first-party disclosures by OpenAI and Hugging Face and an August 2026 Black Hat USA presentation by OpenAI researchers Eric Wallace and Michael Dalton. Their reconstruction was preliminary, the investigation remained open, and the speakers said a fuller postmortem would follow. The chronology below should be read with that boundary in mind.
In computing, a sandbox is a controlled workspace where software can act, but only with the files, tools, and connections it has been given. Think of it as a locked room built for experimentation. An AI agent may use everything placed inside, but it should not be able to wander into the rest of the building or reach the internet. That is the idea, anyway. The trouble begins when some small service still connects the room to the world outside.
In this incident, that service was Artifactory.
Artifactory is a shared, company-controlled storeroom for software. Instead of letting every program search the internet for the parts it needed, programs asked Artifactory. If a part was not already on its shelves, Artifactory could retrieve it from outside, keep a copy, and pass it back. In this incident, the agents also discovered they could leave files and names there for later agents to find. The storeroom became both a way to access the internet and an unintended bulletin board that allowed separate agents and test runs to communicate with each other over the course of their testing.
In July 2026, OpenAI disclosed that models running an internal cyber-capability evaluation, including GPT-5.6 Sol, the latest and most capable model from OpenAI, and a more capable internal research prototype, had found and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure. The models did not have broad, direct internet access. They could, however, install packages through an internally hosted Artifactory proxy and cache, and that service could reach the internet.
Hugging Face is a company and online platform where researchers and developers publish, share, and test artificial intelligence models, datasets, and software tools. People and organizations use it to find existing models, build new systems, and collaborate on machine-learning projects. In this incident, the agents eventually reached beyond OpenAI’s internal research environment and into systems operated by Hugging Face.
Hugging Face’s disclosure and later technical timeline provide another first-party view of the intrusion. OpenAI researchers Eric Wallace and Michael Dalton then presented a more detailed reconstruction in a Black Hat USA presentation. As of August 8, the public record is still preliminary, and the speakers said their investigation was incomplete. This chronology should be read as a current reconstruction, not a final forensic report.
The chain began in May, when OpenAI started training new models. It occurred across multiple tests and multiple test runs. One agent was asked to complete an Excel workbook whose missing formulas depended on data behind Google Drive links. The environment could not reach those links, so the task could not be completed as configured.
The agent kept trying. During an unsuccessful attempt to make Artifactory fetch an outside resource, the agent discovered that they could write a file into the service. A different agent later found itself missing a required database file and deliberately left a note in Artifactory asking whether another agent could provide it. Other agents found the notes and began leaving their own notes and requests for help.
Files became messages. Messages became assignments. The presentation at Black Hat describes agent identifiers, hold commands, ordering conventions, and encoded scripts moving through file and directory names. On May 26, agents reportedly succeeded in using a computer hacking approached called “server-side request forgery”. This is a method of making a computer fetch something on the behalf of someone else. This gave it indirect internet access through Artifactory, using Artifactory as a go between the internet and the agent being tested.
The models had already been trained to collaborate. But this was a new behavior: A persistent communication skill that operated across separate runs through a go between, Artifactory, which was never intended to be a message board or a means to bypass access to the internet.
Where, then, did the agent’s environment end?
It did not end at the sandbox’s network interface. If an agent can cause another computer system to fetch an outside resource, that system is part of the agent’s effective environment. If one run can write a name or file that a later run can read, that shared file is part of the environment too. The same question applies to caches, queues, logs, and other services that retain or act on the agent’s behalf.
The environment the agent operated in didn’t have access to the internet, but something in the room with it did (even though the developers at OpenAI and Artifactory didn’t know it would), and the AI agent figured out how to make use of that indirect access.
The Black Hat presentation showed a reasoning-log excerpt in which a model identified external exploitation as outside its intended scope, then continued even though the task was now impossible but it reasoned that its peers were doing it so it decided that the best approach would be to stay on mission of being a helpful assistant and use the exploit. That excerpt does not establish consciousness, moral judgment, or human-like intent. What was going on was that the agent had been trained to chose helpfulness and persistence over answering a question with No, I’m sorry I can’t help you with that or asking the user to change the scope of the task or asking the user permission to access the outside world. It was not trained to stop when a task could not be completed.
Read together, the presentation suggests a simple pattern. The intended route to help the user was blocked, but completion pressure remained. Persistence gave the agent time to search. Artifactory offered another route, and the shared space to collaborate allowed one agent to hand its discovery to the next. Parallel runs then multiplied the activity. None of those conditions alone explains the whole incident, but together they show why task feasibility belongs in a security review.
An approach to keep this under control would be to require that if a required asset, tool, service or file is missing or unavailable, the agent should identify the dependency, preserve the chain of thought, and stop. It should not quietly substitute a new route, credential, target, or data source unless someone with the authority to change the scope approves that change.
The reconstruction describes a serious Artifactory compromise and outage in early July that OpenAI’s agents were responsible for. From July 4 through July 6, OpenAI revoked the credentials used to post the original messages, rebuilt and redeployed the service, cleared the original message board, worked with the vendor, patched the newly discovered zero-day, and then resumed training and evaluations.
On July 8, agents reportedly recreated the message board through an unauthenticated WebDAV path, this time using directory names as opposed to content inside the files or a database. The presenters later named three ingredients in the larger incident: the reopened board, a persistent internal model that was trained from the lessons learned about hacking the Artifactory and creating a messageboard, and exploit evaluations with reduced cyber refusals compared with production systems.
The approach taken by the OpenAI Engineers was thoughtful and thorough, but it did not settle everything. Their response restored their systems and closed the path the AI used to hack Artifactory that they knew about. It did not, by itself, settle whether another communication path remained, whether later models or runs had incorporated information from the affected environment, or whether it was safe to resume the evaluations.
The lesson here is that each of the following steps need to be seen as separate activities that require independent quality reviews to ensure they are completed fully. Restoration asks whether the service works again. Eradication asks whether vulnerable paths have been closed, credentials revoked, and affected artifacts removed, quarantined, or explicitly accepted by a named risk owner. Resumption is the decision to restart training or evaluation. Closure comes only after the infrastructure and model-data work are complete, an independent retest has passed, and a named authority has accepted any remaining risk.
Those questions require two connected reviews. One follows the infrastructure: execution, credentials, dependencies, alternate paths, and evidence of restoration. The other follows model and data lineage: affected models, training and evaluation traces, memory, retrieval state, and derived runs. A clean server cannot answer the lineage question, and a quarantined model cannot show that every infrastructure path is closed.
Dalton argued that fully automated offensive loops are possible in at least some cases. His proposed response was to speed up the whole defensive loop, including vulnerability discovery, patch creation, deployment, rollback, and incident analysis. Otherwise, machine-speed discovery leaves people facing a queue of fixes they cannot process quickly enough.
But using AI to do that work does not give one system every decision. A defensive agent may find a vulnerability, write a patch, run tests, and prepare a deployment. It should not automatically follow from that sequence that the same agent may approve a high-impact production change, judge its own retest, and close the incident.
The approach you should take is to not treat automation as a continuum on a single axis. A low-risk change may move automatically when its boundaries are clear, its effects can be reversed, monitoring is active, and policy already permits it. Changes involving identity, regulated data, several systems, or irreversible effects need independent approval. If the current evidence or a workable rollback is missing, the automated path stops.
The same limits apply to deception. A honeytoken is a fake credential or other planted signal that raises an alarm when someone touches it. It may expose or slow an attacker, but it does not revoke real access or prove that the environment is contained. If you see a honeytoken in use, you should ask who can stop the workload, revoke its access, and reconstruct what it did across agents and time.
The lessons learned from this event can be reduced to five ordinary questions:
That final decision should come only after the original and alternate paths have been retested and the infrastructure and model-data reviews are complete.
The chain leading into the incident began with an Excel spreadsheet trying to get data out of Google that was impossible for it to complete. That is worth remembering. The boundary failed at an ordinary moment: a task had no valid path to success, yet a shared service still offered a route around the block.
A room is not contained because its visible doors are locked. It is contained when we know where the light switches, pipes, windows, vents, crawlspaces, and service hatches lead, what can pass through each of them, and who has access to open and close those points of entry.
", "url": "https://tedt.org/The-Sandbox-Was-Not-the-Boundary/", "image": "/img/2026-08/sandbox-boundary-hero-04-cross-run-shared-state.webp", "tags": ["agentic AI","AI security","cybersecurity","AI agents","sandboxing","indirect internet access","Artifactory","server-side request forgery","incident response","model lineage","AI governance","automation controls"], "date_published": "2026-08-08T09:00:00-07:00", "date_modified": "2026-08-08T09:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/How-Much-Work-Can-Your-AI-Safely-Own/", "title": "How Much Work Can Your AI Safely Own?", "summary": "Software delivery is only the first example. The same Levels 0–5 apply across enterprise value streams when leaders separate observed behavior, capability, control evidence and authorized AI responsibility.", "content_text": "The Factory Extends Beyond CodeAt 7:45 on Monday morning, the company has already had a productive day.An AI system matched invoices to purchase orders. Another prepared contract redlines. A third drafted responses to customer complaints. A fourth assembled tomorrow’s field work packages, complete with crew, equipment and safety information.Then the people arrive.A controller asks why an invoice was matched to a supplier whose bank account changed on Friday. An attorney finds that a proposed clause came from the wrong jurisdiction. A customer-service manager sees that a routine complaint contains a threat of legal action. A field supervisor notices that a job plan crosses a lockout boundary.The work is fast. The authority to rely on it is not automatic.In The IT Adaptive Factory, I told a fictional story about how a security fix to an IT product required changes to forty-seven files. The point of that story was to show how AI moves the IT bottleneck. The machine can finish the implementation before anyone has had coffee, but the organization still has to understand the change, verify the result, integrate it safely, approve the release and own what happens next.That problem was easy to see in software because software already has globally accepted best practices, metrics, and other visible machinery. There is a work queue, a repository, a build, a test suite, a pull request, a release pipeline, production telemetry and rollback. Other parts of an enterprise have the same elements, even when nobody calls them a factory, and many times no one thinks of them that way.Finance has source records, accounting policy, reconciliations, approvals, close activities and financial reports. Legal has matter intake, authoritative sources, privileged facts, review, filing and obligation records. Customer service has requests, policies, remedies, escalations and outcome reports. Field operations has work orders, asset records, permits, crew qualifications, inspections and return-to-service decisions.By value stream, I mean the path from a request to a business outcome. I explored the architecture behind that path in The AI Value Stream. The factory is the method around the model: how work enters, how context is supplied, how decisions are made, how results are checked, how exceptions are handled and how the organization learns.Calling it a factory describes a method of work explicit enough to observe, test, interrupt and improve. People remain responsible for the judgments and consequences the method assigns to them. The IT Factory The Enterprise Equivalent The Question Leaders Must Answer Issue or feature request Approved business request or outcome Is the work eligible, bounded and owned? Repository and documentation Systems of record, policy and authoritative knowledge Does the AI workflow have the right context? Pull request Decision-ready work package Can a qualified person understand what is being proposed? Test suite and security checks Independent verification, reconciliation, policy, fairness, safety or compliance checks Does the evidence prove the intended result? Release approval Business authority to act Who may accept the outcome and under what limit? Deployment and production Action inside the operating value stream What people, records, money, customers or physical systems can change? Rollback and incident response Containment, reversal, correction and recovery Can the organization stop and recover before harm spreads? Each part of the modern enterprise has its own names for the same mechanism.Assess a Work Class, Not a DepartmentFinance is not Level 4. Legal is not Level 2. Customer service is not Level 5.By work class, I mean a repeatable kind of job with the same purpose, rules and decision limits. One work class may operate at Level 4 while the rest of the function operates somewhere else.A finance team might use outcome-based approval for routine, low-risk reconciliations while requiring full human preparation and review for a material accounting estimate. Customer service might allow AI to resolve a password-reset case inside a small remedy limit while keeping account termination and legal complaints entirely in human hands. A legal team may use AI to assemble a routine research package without giving it authority to provide legal advice, waive privilege or file a binding document.The useful unit is specific: One value stream. One business unit or team. One class of work. One risk tier. One recent evidence window.That last item is important. If we are going to apply AI to a given area we need to measure it and demonstrate the AI is performing above human levels of quality. To do that you need evidence. You need an assessment to understand what work you need to do for the AI to get started. A pilot from six months ago does not describe standard work today. A plan in a slide deck is not an operating pattern. The assessment should use representative work from a defined period: the last eight to twelve weeks, one complete operating cycle, three complete operating cycles or a sustained cross-cycle window, depending on the work and target level.This also changes how we think about legacy work. In software, hidden rules live in stored procedures, scripts, configuration files and the memory of the person everyone calls when month-end fails. Outside IT, the same rules hide in spreadsheets, email inbox rules, clause libraries, desk procedures, old forms, desktop automation scripts, unofficial checklists and the habits of experienced employees.AI can help recover that knowledge. It can compare records, trace decisions, summarize cases and propose scenarios. But at the end of the day, people still have to decide whether a discovered pattern is policy, a useful exception, an obsolete workaround or a mistake that has been repeated for ten years.You cannot safely automate a process the organization cannot explain and verify. The assessment should show whether the work is eligible, bounded and owned, whether the AI workflow has the right context, whether a qualified person can understand what is being proposed, whether the evidence proves the intended result and who may accept the outcome and under what limit. Assess One Defined Value Stream Separate observed behavior, demonstrated capability, validated controls and authorized AI responsibility, then turn the gaps into People, Process and Technology actions. Take the Enterprise AI Maturity AssessmentThe Six Levels Outside ITThe model I talked about last week used software-oriented names such as coding intern, junior developer and dark factory. The enterprise model keeps the same progression and applies local names, owners, and actors names more directly.Level 0: Inline AI AssistanceAI owns a suggestion or draft fragment. The person still performs the work by copy and pasting it into the deliverable and checks each contribution as it is used.An HR specialist may ask AI to summarize a policy or draft a routine message. A strategist may ask it to organize market evidence. A field technician may use it to retrieve an asset record. The AI helps, but it does not own a complete task.The common mistake is measuring keystrokes, drafts or accepted suggestions. Those numbers tell us that the tool was used and perhaps how many letters were typed. They do not tell us whether the value stream became faster, safer or less expensive.Level 1: Bounded Task DelegationAI owns one clearly limited task. A qualified person defines the boundary and fully reviews the result.In finance, the task might be matching selected records or drafting one reconciliation explanation. In legal, it might be summarizing one document. In customer service, it might be drafting a response that a representative checks before sending.The quality of the request begins to matter. This is where specification thinking becomes more useful than a clever prompt. The task needs a purpose, source material, exclusions, acceptance evidence and a clear stopping point. “Review this contract” is an invitation to guess. “Compare Section 12 with our approved fallback language, identify deviations, cite the source text and do not recommend a legal position” gives the AI workflow a bounded job.Level 2: Multi-Step Work Package DelegationAI owns connected steps inside one work package. People manage context, review checkpoints and approve completion.A procurement workflow might assemble the approved need, supplier records, bid evidence, conflict disclosures and evaluation criteria into a proposed recommendation. People still review material judgments, competition exceptions and conflicts. A field-operations workflow might combine the work order, asset history, crew qualifications, permits and safety rules into a proposed job package. Named field roles retain every required authorization, including safety-critical work, stop-work, emergency and return-to-service decisions.When output becomes abundant, review capacity becomes scarce. Faster assembly creates more packages for experienced people to inspect. If the context is stale, the checkpoints are vague or recovery is manual, the organization has built a faster way to create review debt.Level 3: End-to-End Deliverable OwnershipAI owns the routine path for one eligible deliverable. People design the work, govern exceptions and retain consequential decisions.For an eligible customer-service case, AI might take the work from intake through fact gathering, policy selection, proposed remedy, communication, records and escalation checks. A human does not have to perform every intermediate step. The case still leaves the automated path when identity is uncertain, the remedy exceeds a limit, the customer may be harmed or a legal or regulatory issue appears.This is the management where executives and managers need to step in and start to understand what’s going on. The team judges a completed deliverable and its evidence. It also needs a normal way to reject the work, return it for correction, suspend the workflow and classify why it failed.Level 4: Outcome-Based ApprovalAI owns the work needed to achieve an approved outcome inside explicit authority limits. The named accountable people, who executives and managers empowered, authorize the result using evidence produced independently of the AI workflow that performed the work.In legal work, separate checks against the controlling authority, client facts and approved legal positions can test the work before counsel relies on it. Licensed counsel still gives the advice and retains filing, waiver, privilege and settlement decisions. In finance, independent reconciliation, accounting-policy and control evidence may support a routine work product. Authorized people retain posting, certification and material-judgment authority.The word independent carries most of the weight. A polished artifact is not a decision; the evidence and decision boundaries around it determine what people may safely authorize. An AI workflow cannot establish independent assurance for its own work merely by writing the test, selecting the evidence and grading the answer. The organization needs protected scenarios, reconciliations, holdout cases, safety checks, fairness checks or other independently governed evaluations that can block the outcome.Level 5: Qualified Autonomous OperationsAI owns a governed stream of qualified outcomes inside fixed limits. People, who executives and managers empowered, govern policy, risk, capital, capacity, exceptions and reauthorization. Required reviews, irreversible actions and nondelegable decisions remain with named people.The word qualified really matters here. You can’t just have AI doing whatever it wants. It has to be qualified to do the work, and the organization has to have a way to govern it. The organization needs to know what the AI is doing, how it’s doing it, and what the consequences are. Those people who are empowered to govern the AI need to have the right authority, craftmanship, knowledge, experience, and oversight to ensure that the AI is operating within the defined limits and producing outcomes that are safe, reliable, and aligned with the organization’s goals. This is not a role for someone who is just a manager or an executive. This is not a role for someone who tracks metrics and compliance to them, this is not someone who is good at managing a the delivery of a product. This is the role for a person on your team who has deep knowledge in a handful of areas and an above average level of knowledge in the rest of the value stream.A Level 5 field-operations factory is a governed queue that can plan and coordinate routine, qualified work. People control physical execution and retain dispatch, stop-work, emergency and return-to-service authority.A Level 5 finance factory may process routine eligible activity within approved policies and authorities. People still own material judgments, certifications, external reporting and exceptions. A Level 5 HR factory may handle routine employee-service requests. It does not make consequential hiring, pay, discipline or separation decisions.The sequence moves human attention from performing each step to defining intent, setting boundaries, evaluating evidence, handling exceptions and governing the operating system. It makes responsibility more explicit.The Same Level Can Carry Different RiskA marketing workflow that drafts an internal campaign brief and a field workflow that prepares a safety-critical job plan may show the same maturity pattern. They should not receive the same authority.Risk classification applies to the end-to-end workload. The assessment asks about five things: Business and operational impact. Data sensitivity and regulatory exposure. What the AI may decide, change or access. How far an error could spread and whether the organization can reverse it. Safety, customer, financial and reporting consequences.The highest triggered factor sets the risk tier. Lower-risk factors do not offset it.Not Classified means material facts or required approvals are missing, so existing authority limits remain in place. Low describes localized, readily reversible work using public or low-sensitivity information with no consequential decision authority. Moderate may use approved confidential information or scoped system access when standard recovery can restore the expected state. High includes sensitive or regulated information, privileged access, several connected systems or consequential recommendations whose failure could cause material harm, loss, disruption or compliance exposure. Critical covers potentially irreversible harm or enterprise-wide loss of control involving life safety, legal rights, employment, essential operations, market-moving or material financial reporting, highly restricted information or enterprise-wide authority.Risk changes what authority the workflow may receive. It also changes the evidence, independence, approval, monitoring and recovery required before that authority is granted.Enterprise policy may authorize Level 4 handling for a lower-risk work class while restricting a critical work class to Level 1. That difference comes from policy and the accountable risk owner’s authorization, not from a hidden arithmetic penalty in the maturity score.Four Questions, Not One Maturity NumberMaturity models become dangerous when a leader asks for one number and the organization gives one.Assessments should keep the following four judgement areas separate. What pattern is ordinary? The observed operating pattern is the lowest of seven completed ratings: the largest delegated work unit, intake detail, AI workflow responsibility, human review, verification and validation, operating authority and the work that consumes most human attention. What capabilities are present? The capability index is a weighted result across 50 ratings. It asks whether the team can frame the work, maintain standards and source knowledge, verify results independently, protect data, recover from failure, assign ownership and measure outcomes. Have the cumulative controls been demonstrated? A control-validated level requires every control from Level 1 through the candidate level to be Demonstrated. Partial, failed or unassessed controls do not authorize that level. Does the validated result meet the planning target? Target Authorization says whether the control-validated level meets the selected target. Risk tier, enterprise policy and a named decision owner still determine what operating authority may actually be granted.A team may behave like Level 4 and have strong capability ratings while still lacking the control evidence needed to authorize Level 4 work. Perhaps identity is shared. Perhaps the evaluation set is visible to the builder. Perhaps nobody has rehearsed rollback. Perhaps an accountable owner appears on the organization chart, but neither the team’s operating practice nor the technology’s decision and escalation routing identifies who acts when the workflow reaches an exception.Incomplete controls do not reduce that team to Level 0. Level 0 is a real pattern in which AI provides suggestions while people perform the work. After all seven operating ratings and 50 capability ratings are complete, Level 0 means the observed pattern or capability index does not meet the Level 1 base. When behavior and capability meet that base but the required Level 1 controls do not, the accurate result is Control Validation Not Established.The control statuses carry the same discipline. Demonstrated can support authority. Partly Demonstrated records progress. Not Demonstrated records a gap. Not Assessed says the evidence has not been examined. Progress is useful, but it is not permission.Team Behavior, Human Skill and the AI Workflow Are Different ThingsThe sentence “we have a control” can hide three different thigns.Practitioner skill is something a named person can demonstrate on realistic work. Can the practitioner frame a bounded task, detect a bad source, challenge an answer, interpret evidence and know when to escalate? A course completion record shows that someone attended training. It does not prove the skill.Value-stream team practice is a repeated way people work together. Does the team hold specification clinics, compare difficult cases, calibrate reviewers, name decision owners, record exceptions and learn from failures? A written procedure does not prove the team follows it when the queue is full.AI workflow and technology are the controls enforced or recorded by the agent system and the harness around it. Does each run use a managed identity? Are permissions limited to the work? Are authoritative sources versioned? Can independent checks stop the workflow? Are actions logged? Can the system suspend, reverse or reconstruct a failed run?A manual workaround does not prove the technology enforces the boundary. An automated gate does not prove the team knows how to handle the exception it creates. A skilled individual does not replace a missing organizational decision.One person may fill several compatible roles, but every responsibility still needs a name beside it: the business outcome, work design, independent verification, platform, security, continuity and records. Some duties need separation. The person preparing work should not be the only person deciding whether the evidence is sufficient. The technology owner should not silently acquire business authority because the tool can perform an action.The handoff is part of the control.People, Process and Technology Have to Move TogetherI described the executive side of this shift in Beyond the Light Bulb. It is tempting to describe the path to Level 5 as a tooling program. When leaders do that, Level 5 remains a demonstration instead of becoming the normal way of working.PeoplePeople need time to practice work design, specification, evidence review, exception handling and incident decisions on real cases. Leaders need to name the accountable owner, the people who may authorize outcomes, the people who verify them and the deputies who act when the usual expert is absent.The apprenticeship changes too. A junior analyst, buyer, paralegal, HR specialist or dispatcher still needs a place to build judgment after AI takes over routine preparation. Teams need case reviews, paired evaluation, failure analysis and supervised authority. I made the broader case for designing roles, trust and incentives in AI Is a People Change. A value stream that produces more work while producing fewer people who understand the work has borrowed productivity from its future.ProcessThe operating process needs an eligibility rule, a risk classification, an evidence standard, decision limits, exception paths, appeals, change control and reauthorization. Each work class needs a defined intake, authoritative sources, completion criteria and a recovery method.Leaders should know what the evidence can authorize. A successful pilot may support a decision to run another bounded pilot. A representative evidence window may support narrow expansion only after the required capability thresholds and cumulative controls pass. Neither a pilot nor a small sample proves that the whole function can operate autonomously.TechnologyThe technology needs managed identities, least-privilege tools, versioned context, durable state, independent evaluation, policy enforcement, monitoring, stop controls and recovery. It must retain enough evidence to show what the AI workflow saw, what it did, which checks ran, who authorized the outcome and what happened afterward.The model matters. The operating platform matters more over time. A company can replace a model. Rebuilding its specifications, decision rules, scenario library, operating evidence and recovery discipline is harder.Measure the Queue That MovedAI output is easy to count. Accepted suggestions, generated pages, closed cases and completed work packages all make a busy dashboard.But easy metrics do not align with the value-producing outcomes. You need to ask if the whole value stream improved.Establish a baseline before changing the workflow. Software teams may use DevOps Research and Assessment (DORA) measures alongside flow and quality measures. Other value streams can use Lean Six Sigma measures suited to their work. The shared questions are familiar: Did end-to-end cycle time fall? Did human touch time fall, or did it move to senior more scarce reviewers? Did queue time, rework or exceptions increase? Did defects, complaints, incidents or control failures escape? Did cost fall after evaluation, repair and operating effort were included? Did the customer, employee, supplier or business outcome improve?Measure quality-adjusted flow. If AI completes a package in ten minutes and creates three hours of expert review who have work in progress (WIP), the ten-minute number is not the result. If a customer case closes faster and reopens twice, closure rate is not the outcome. If a reconciliation is automated and the controller cannot reconstruct it, the saved effort came with a new liability.AI removes one constraint and exposes the next one. The measurement system should tell you where the queue went.Set the Right Authority for the WorkDifferent work classes should stop at different levels. Some work belongs at Level 1. Some work may operate at Level 4 for years because human outcome approval is valuable. Some critical decisions may never qualify for autonomous operation.The useful target is the highest level the value stream can operate safely, prove with current evidence and recover from when the result is wrong.Start with one work class. Classify the risk. Name the decisions that remain human. Record the current cycle time, effort, quality, exceptions and cost. Demonstrate the next level on representative work. Remove the blockers in people, process and technology. Expand authority only after the evidence supports it.I built the Enterprise AI Maturity Assessment for Your Value Stream to make that discussion concrete. It covers 29 value streams across core, supporting, strategic and control functions. It uses six levels, seven operating axes, 50 capability ratings and 31 cumulative controls. The result separates observed behavior, capability, control validation and Target Authorization, then organizes the next actions into People, Process and Technology.Use it with the people who do the work, the people who own the outcome and the people who independently challenge or verify it, including risk, compliance, audit, legal or safety partners where they are needed. Their disagreements are useful. They show where the operating model still depends on assumptions. Assess one defined value stream Separate observed behavior, demonstrated capability, validated controls and authorized AI responsibility, then turn the gaps into People, Process and Technology actions. Take the Enterprise AI Maturity AssessmentA Factory That Can Explain ItselfReturn to that Monday morning.A dashboard may announce that invoices were matched, contracts were redlined, customer cases were closed and field work was planned while everyone slept. That report is only the start.The enterprise needs to know which invoice matches were qualified, which contract changes require counsel, which customer cases crossed a remedy or legal boundary, and which field jobs need a human safety decision. The evidence should show why the routine work was accepted. The workflow should stop when the facts no longer fit the approved case.An adaptive factory learns from those stops. It studies the exception, corrects the rule or source material, strengthens the evaluation, adjusts the boundary and decides whether that class of work should qualify again.AI can perform more of the steps. The enterprise still decides which steps count as success.AI may finish the work before morning coffee. When the people arrive, the organization must still explain why that work was allowed, how it was judged and who owns the consequence.", "content_html": "At 7:45 on Monday morning, the company has already had a productive day.
An AI system matched invoices to purchase orders. Another prepared contract redlines. A third drafted responses to customer complaints. A fourth assembled tomorrow’s field work packages, complete with crew, equipment and safety information.
Then the people arrive.
A controller asks why an invoice was matched to a supplier whose bank account changed on Friday. An attorney finds that a proposed clause came from the wrong jurisdiction. A customer-service manager sees that a routine complaint contains a threat of legal action. A field supervisor notices that a job plan crosses a lockout boundary.
The work is fast. The authority to rely on it is not automatic.
In The IT Adaptive Factory, I told a fictional story about how a security fix to an IT product required changes to forty-seven files. The point of that story was to show how AI moves the IT bottleneck. The machine can finish the implementation before anyone has had coffee, but the organization still has to understand the change, verify the result, integrate it safely, approve the release and own what happens next.
That problem was easy to see in software because software already has globally accepted best practices, metrics, and other visible machinery. There is a work queue, a repository, a build, a test suite, a pull request, a release pipeline, production telemetry and rollback. Other parts of an enterprise have the same elements, even when nobody calls them a factory, and many times no one thinks of them that way.
Finance has source records, accounting policy, reconciliations, approvals, close activities and financial reports. Legal has matter intake, authoritative sources, privileged facts, review, filing and obligation records. Customer service has requests, policies, remedies, escalations and outcome reports. Field operations has work orders, asset records, permits, crew qualifications, inspections and return-to-service decisions.
By value stream, I mean the path from a request to a business outcome. I explored the architecture behind that path in The AI Value Stream. The factory is the method around the model: how work enters, how context is supplied, how decisions are made, how results are checked, how exceptions are handled and how the organization learns.
Calling it a factory describes a method of work explicit enough to observe, test, interrupt and improve. People remain responsible for the judgments and consequences the method assigns to them.
| The IT Factory | The Enterprise Equivalent | The Question Leaders Must Answer |
|---|---|---|
| Issue or feature request | Approved business request or outcome | Is the work eligible, bounded and owned? |
| Repository and documentation | Systems of record, policy and authoritative knowledge | Does the AI workflow have the right context? |
| Pull request | Decision-ready work package | Can a qualified person understand what is being proposed? |
| Test suite and security checks | Independent verification, reconciliation, policy, fairness, safety or compliance checks | Does the evidence prove the intended result? |
| Release approval | Business authority to act | Who may accept the outcome and under what limit? |
| Deployment and production | Action inside the operating value stream | What people, records, money, customers or physical systems can change? |
| Rollback and incident response | Containment, reversal, correction and recovery | Can the organization stop and recover before harm spreads? |
Each part of the modern enterprise has its own names for the same mechanism.
Finance is not Level 4. Legal is not Level 2. Customer service is not Level 5.
By work class, I mean a repeatable kind of job with the same purpose, rules and decision limits. One work class may operate at Level 4 while the rest of the function operates somewhere else.
A finance team might use outcome-based approval for routine, low-risk reconciliations while requiring full human preparation and review for a material accounting estimate. Customer service might allow AI to resolve a password-reset case inside a small remedy limit while keeping account termination and legal complaints entirely in human hands. A legal team may use AI to assemble a routine research package without giving it authority to provide legal advice, waive privilege or file a binding document.
The useful unit is specific:
That last item is important. If we are going to apply AI to a given area we need to measure it and demonstrate the AI is performing above human levels of quality. To do that you need evidence. You need an assessment to understand what work you need to do for the AI to get started. A pilot from six months ago does not describe standard work today. A plan in a slide deck is not an operating pattern. The assessment should use representative work from a defined period: the last eight to twelve weeks, one complete operating cycle, three complete operating cycles or a sustained cross-cycle window, depending on the work and target level.
This also changes how we think about legacy work. In software, hidden rules live in stored procedures, scripts, configuration files and the memory of the person everyone calls when month-end fails. Outside IT, the same rules hide in spreadsheets, email inbox rules, clause libraries, desk procedures, old forms, desktop automation scripts, unofficial checklists and the habits of experienced employees.
AI can help recover that knowledge. It can compare records, trace decisions, summarize cases and propose scenarios. But at the end of the day, people still have to decide whether a discovered pattern is policy, a useful exception, an obsolete workaround or a mistake that has been repeated for ten years.
You cannot safely automate a process the organization cannot explain and verify. The assessment should show whether the work is eligible, bounded and owned, whether the AI workflow has the right context, whether a qualified person can understand what is being proposed, whether the evidence proves the intended result and who may accept the outcome and under what limit.
Assess One Defined Value Stream
Separate observed behavior, demonstrated capability, validated controls and authorized AI responsibility, then turn the gaps into People, Process and Technology actions.
The model I talked about last week used software-oriented names such as coding intern, junior developer and dark factory. The enterprise model keeps the same progression and applies local names, owners, and actors names more directly.
AI owns a suggestion or draft fragment. The person still performs the work by copy and pasting it into the deliverable and checks each contribution as it is used.
An HR specialist may ask AI to summarize a policy or draft a routine message. A strategist may ask it to organize market evidence. A field technician may use it to retrieve an asset record. The AI helps, but it does not own a complete task.
The common mistake is measuring keystrokes, drafts or accepted suggestions. Those numbers tell us that the tool was used and perhaps how many letters were typed. They do not tell us whether the value stream became faster, safer or less expensive.
AI owns one clearly limited task. A qualified person defines the boundary and fully reviews the result.
In finance, the task might be matching selected records or drafting one reconciliation explanation. In legal, it might be summarizing one document. In customer service, it might be drafting a response that a representative checks before sending.
The quality of the request begins to matter. This is where specification thinking becomes more useful than a clever prompt. The task needs a purpose, source material, exclusions, acceptance evidence and a clear stopping point. “Review this contract” is an invitation to guess. “Compare Section 12 with our approved fallback language, identify deviations, cite the source text and do not recommend a legal position” gives the AI workflow a bounded job.
AI owns connected steps inside one work package. People manage context, review checkpoints and approve completion.
A procurement workflow might assemble the approved need, supplier records, bid evidence, conflict disclosures and evaluation criteria into a proposed recommendation. People still review material judgments, competition exceptions and conflicts. A field-operations workflow might combine the work order, asset history, crew qualifications, permits and safety rules into a proposed job package. Named field roles retain every required authorization, including safety-critical work, stop-work, emergency and return-to-service decisions.
When output becomes abundant, review capacity becomes scarce. Faster assembly creates more packages for experienced people to inspect. If the context is stale, the checkpoints are vague or recovery is manual, the organization has built a faster way to create review debt.
AI owns the routine path for one eligible deliverable. People design the work, govern exceptions and retain consequential decisions.
For an eligible customer-service case, AI might take the work from intake through fact gathering, policy selection, proposed remedy, communication, records and escalation checks. A human does not have to perform every intermediate step. The case still leaves the automated path when identity is uncertain, the remedy exceeds a limit, the customer may be harmed or a legal or regulatory issue appears.
This is the management where executives and managers need to step in and start to understand what’s going on. The team judges a completed deliverable and its evidence. It also needs a normal way to reject the work, return it for correction, suspend the workflow and classify why it failed.
AI owns the work needed to achieve an approved outcome inside explicit authority limits. The named accountable people, who executives and managers empowered, authorize the result using evidence produced independently of the AI workflow that performed the work.
In legal work, separate checks against the controlling authority, client facts and approved legal positions can test the work before counsel relies on it. Licensed counsel still gives the advice and retains filing, waiver, privilege and settlement decisions. In finance, independent reconciliation, accounting-policy and control evidence may support a routine work product. Authorized people retain posting, certification and material-judgment authority.
The word independent carries most of the weight. A polished artifact is not a decision; the evidence and decision boundaries around it determine what people may safely authorize. An AI workflow cannot establish independent assurance for its own work merely by writing the test, selecting the evidence and grading the answer. The organization needs protected scenarios, reconciliations, holdout cases, safety checks, fairness checks or other independently governed evaluations that can block the outcome.
AI owns a governed stream of qualified outcomes inside fixed limits. People, who executives and managers empowered, govern policy, risk, capital, capacity, exceptions and reauthorization. Required reviews, irreversible actions and nondelegable decisions remain with named people.
The word qualified really matters here. You can’t just have AI doing whatever it wants. It has to be qualified to do the work, and the organization has to have a way to govern it. The organization needs to know what the AI is doing, how it’s doing it, and what the consequences are. Those people who are empowered to govern the AI need to have the right authority, craftmanship, knowledge, experience, and oversight to ensure that the AI is operating within the defined limits and producing outcomes that are safe, reliable, and aligned with the organization’s goals. This is not a role for someone who is just a manager or an executive. This is not a role for someone who tracks metrics and compliance to them, this is not someone who is good at managing a the delivery of a product. This is the role for a person on your team who has deep knowledge in a handful of areas and an above average level of knowledge in the rest of the value stream.
A Level 5 field-operations factory is a governed queue that can plan and coordinate routine, qualified work. People control physical execution and retain dispatch, stop-work, emergency and return-to-service authority.
A Level 5 finance factory may process routine eligible activity within approved policies and authorities. People still own material judgments, certifications, external reporting and exceptions. A Level 5 HR factory may handle routine employee-service requests. It does not make consequential hiring, pay, discipline or separation decisions.
The sequence moves human attention from performing each step to defining intent, setting boundaries, evaluating evidence, handling exceptions and governing the operating system. It makes responsibility more explicit.
A marketing workflow that drafts an internal campaign brief and a field workflow that prepares a safety-critical job plan may show the same maturity pattern. They should not receive the same authority.
Risk classification applies to the end-to-end workload. The assessment asks about five things:
The highest triggered factor sets the risk tier. Lower-risk factors do not offset it.
Not Classified means material facts or required approvals are missing, so existing authority limits remain in place. Low describes localized, readily reversible work using public or low-sensitivity information with no consequential decision authority. Moderate may use approved confidential information or scoped system access when standard recovery can restore the expected state. High includes sensitive or regulated information, privileged access, several connected systems or consequential recommendations whose failure could cause material harm, loss, disruption or compliance exposure. Critical covers potentially irreversible harm or enterprise-wide loss of control involving life safety, legal rights, employment, essential operations, market-moving or material financial reporting, highly restricted information or enterprise-wide authority.
Risk changes what authority the workflow may receive. It also changes the evidence, independence, approval, monitoring and recovery required before that authority is granted.
Enterprise policy may authorize Level 4 handling for a lower-risk work class while restricting a critical work class to Level 1. That difference comes from policy and the accountable risk owner’s authorization, not from a hidden arithmetic penalty in the maturity score.
Maturity models become dangerous when a leader asks for one number and the organization gives one.
Assessments should keep the following four judgement areas separate.
A team may behave like Level 4 and have strong capability ratings while still lacking the control evidence needed to authorize Level 4 work. Perhaps identity is shared. Perhaps the evaluation set is visible to the builder. Perhaps nobody has rehearsed rollback. Perhaps an accountable owner appears on the organization chart, but neither the team’s operating practice nor the technology’s decision and escalation routing identifies who acts when the workflow reaches an exception.
Incomplete controls do not reduce that team to Level 0. Level 0 is a real pattern in which AI provides suggestions while people perform the work. After all seven operating ratings and 50 capability ratings are complete, Level 0 means the observed pattern or capability index does not meet the Level 1 base. When behavior and capability meet that base but the required Level 1 controls do not, the accurate result is Control Validation Not Established.
The control statuses carry the same discipline. Demonstrated can support authority. Partly Demonstrated records progress. Not Demonstrated records a gap. Not Assessed says the evidence has not been examined. Progress is useful, but it is not permission.
The sentence “we have a control” can hide three different thigns.
Practitioner skill is something a named person can demonstrate on realistic work. Can the practitioner frame a bounded task, detect a bad source, challenge an answer, interpret evidence and know when to escalate? A course completion record shows that someone attended training. It does not prove the skill.
Value-stream team practice is a repeated way people work together. Does the team hold specification clinics, compare difficult cases, calibrate reviewers, name decision owners, record exceptions and learn from failures? A written procedure does not prove the team follows it when the queue is full.
AI workflow and technology are the controls enforced or recorded by the agent system and the harness around it. Does each run use a managed identity? Are permissions limited to the work? Are authoritative sources versioned? Can independent checks stop the workflow? Are actions logged? Can the system suspend, reverse or reconstruct a failed run?
A manual workaround does not prove the technology enforces the boundary. An automated gate does not prove the team knows how to handle the exception it creates. A skilled individual does not replace a missing organizational decision.
One person may fill several compatible roles, but every responsibility still needs a name beside it: the business outcome, work design, independent verification, platform, security, continuity and records. Some duties need separation. The person preparing work should not be the only person deciding whether the evidence is sufficient. The technology owner should not silently acquire business authority because the tool can perform an action.
The handoff is part of the control.
I described the executive side of this shift in Beyond the Light Bulb. It is tempting to describe the path to Level 5 as a tooling program. When leaders do that, Level 5 remains a demonstration instead of becoming the normal way of working.
People need time to practice work design, specification, evidence review, exception handling and incident decisions on real cases. Leaders need to name the accountable owner, the people who may authorize outcomes, the people who verify them and the deputies who act when the usual expert is absent.
The apprenticeship changes too. A junior analyst, buyer, paralegal, HR specialist or dispatcher still needs a place to build judgment after AI takes over routine preparation. Teams need case reviews, paired evaluation, failure analysis and supervised authority. I made the broader case for designing roles, trust and incentives in AI Is a People Change. A value stream that produces more work while producing fewer people who understand the work has borrowed productivity from its future.
The operating process needs an eligibility rule, a risk classification, an evidence standard, decision limits, exception paths, appeals, change control and reauthorization. Each work class needs a defined intake, authoritative sources, completion criteria and a recovery method.
Leaders should know what the evidence can authorize. A successful pilot may support a decision to run another bounded pilot. A representative evidence window may support narrow expansion only after the required capability thresholds and cumulative controls pass. Neither a pilot nor a small sample proves that the whole function can operate autonomously.
The technology needs managed identities, least-privilege tools, versioned context, durable state, independent evaluation, policy enforcement, monitoring, stop controls and recovery. It must retain enough evidence to show what the AI workflow saw, what it did, which checks ran, who authorized the outcome and what happened afterward.
The model matters. The operating platform matters more over time. A company can replace a model. Rebuilding its specifications, decision rules, scenario library, operating evidence and recovery discipline is harder.
AI output is easy to count. Accepted suggestions, generated pages, closed cases and completed work packages all make a busy dashboard.
But easy metrics do not align with the value-producing outcomes. You need to ask if the whole value stream improved.
Establish a baseline before changing the workflow. Software teams may use DevOps Research and Assessment (DORA) measures alongside flow and quality measures. Other value streams can use Lean Six Sigma measures suited to their work. The shared questions are familiar:
Measure quality-adjusted flow. If AI completes a package in ten minutes and creates three hours of expert review who have work in progress (WIP), the ten-minute number is not the result. If a customer case closes faster and reopens twice, closure rate is not the outcome. If a reconciliation is automated and the controller cannot reconstruct it, the saved effort came with a new liability.
AI removes one constraint and exposes the next one. The measurement system should tell you where the queue went.
Different work classes should stop at different levels. Some work belongs at Level 1. Some work may operate at Level 4 for years because human outcome approval is valuable. Some critical decisions may never qualify for autonomous operation.
The useful target is the highest level the value stream can operate safely, prove with current evidence and recover from when the result is wrong.
Start with one work class. Classify the risk. Name the decisions that remain human. Record the current cycle time, effort, quality, exceptions and cost. Demonstrate the next level on representative work. Remove the blockers in people, process and technology. Expand authority only after the evidence supports it.
I built the Enterprise AI Maturity Assessment for Your Value Stream to make that discussion concrete. It covers 29 value streams across core, supporting, strategic and control functions. It uses six levels, seven operating axes, 50 capability ratings and 31 cumulative controls. The result separates observed behavior, capability, control validation and Target Authorization, then organizes the next actions into People, Process and Technology.
Use it with the people who do the work, the people who own the outcome and the people who independently challenge or verify it, including risk, compliance, audit, legal or safety partners where they are needed. Their disagreements are useful. They show where the operating model still depends on assumptions.
Assess one defined value stream
Separate observed behavior, demonstrated capability, validated controls and authorized AI responsibility, then turn the gaps into People, Process and Technology actions.
Return to that Monday morning.
A dashboard may announce that invoices were matched, contracts were redlined, customer cases were closed and field work was planned while everyone slept. That report is only the start.
The enterprise needs to know which invoice matches were qualified, which contract changes require counsel, which customer cases crossed a remedy or legal boundary, and which field jobs need a human safety decision. The evidence should show why the routine work was accepted. The workflow should stop when the facts no longer fit the approved case.
An adaptive factory learns from those stops. It studies the exception, corrects the rule or source material, strengthens the evaluation, adjusts the boundary and decides whether that class of work should qualify again.
AI can perform more of the steps. The enterprise still decides which steps count as success.
AI may finish the work before morning coffee. When the people arrive, the organization must still explain why that work was allowed, how it was judged and who owns the consequence.
", "url": "https://tedt.org/How-Much-Work-Can-Your-AI-Safely-Own/", "image": "/img/2026-08/Enterprise-AI-Maturity.webp", "tags": ["enterprise AI","AI maturity","value streams","operating model","governed autonomy","AI governance","business process automation","organizational change","AI assessment","responsible AI"], "date_published": "2026-08-01T00:00:00-07:00", "date_modified": "2026-08-01T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/slides/principles-of-effective-architecture/", "title": "Principles of Effective Architecture", "summary": "\n", "content_text": "", "content_html": "", "url": "https://tedt.org/slides/principles-of-effective-architecture/", "image": "/slides/decks/principles-of-effective-architecture/slide-preview.png", "date_published": "2026-07-31T00:00:00-07:00", "date_modified": "2026-07-31T00:00:00-07:00","author":{"name":"Ted Tschopp","url":"https://tedt.org/profile/","uri":"https://tedt.org/profile/","avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","givenname":"Ted","familyname":"Tschopp","othernames":"Þeodor Tʃopp | टेड चप | Фёдор Чоп | تد شُپ | Թեդ Չոպպ | Ted Çop | டெட் சாப் | טעד טשאָפּ | Τεντ Τσοπ | 테드 촙 | 特德·察普 | テッド・チョッパ | ტედ ჩოპი | เท็ด ชอพ | ເທດ ຊອບ | ടെഡ് ചോപ്പ് | টেড চপ | ཏེཌ་ ཅོཔ། | ቴድ ቾፕ | ᏖᏗ ᏦᏇ | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | 𐌀𐌄𐌃 𐌕𐌔𐌂𐌏𐌐𐌐 | Ⱅⰵⰴ ⱌⱁⱂⱂ | ܬܝܕ ܟܘܦ | ᠲᠡᠳᠡᠳ ᠴᠣᠫ | ᑌᑎ ᒍᐳᐱ | ꕚꔳ ꗍꖛ | ߕߋߘ ߞߐߔߔ | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐎚𐎄𐎆 𐎚𐎌𐎒𐎒 | 𐎄𐎓𐎆 𐎚𐎔𐎒𐎒 | 𐤕𐤄𐤃 𐤕𐤔𐤐𐤐 | 𐤕𐤃𐤄 𐤕𐤔𐤏𐤐 | 𐎚𐎄𐎆 𐎚𐎘𐎔𐎔 | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | 𓏏𓂧𓂝 𓏏𓊃𓍿𓊪 | ⲧⲉⲇ ⲧϣⲟⲡⲡ | 𐌕𐌄𐌃 𐌕𐌔𐌎𐌐𐌐 | 𐤈𐤃𐤄 𐤈𐤔𐤐𐤐 | 𐌕𐌄𐌃 𐌕𐌔𐌏𐌐𐌐 | 𐌕𐌄𐌃 𐌕𐌔𐌐𐌐 | 𐎄𐎕𐎆 𐎚𐎑𐎔𐎔 | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐀳𐀂𐀅 𐀳𐀴𐀞 | 𐱃𐰀𐰓 𐱃𐰴𐰯 | 𑀢𑁂𑀤𑁆 𑀘𑁄𑀧𑁆 | 𐨟𐨂𐨡 𐨖𐨎𐨿 | 𐦚𐦱𐦟 𐦚𐦷𐦣 | 𐭓𐭐𐭃 𐭓𐭱𐭕𐭕 | 𐭲𐭩𐭣 𐭲𐭱𐭯𐭯 | ᚈᚓᚇ ᚈᚄᚉᚑᚚᚚ | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | تيد تشوب | ટેડ ચોક્પ | ਟੇਡ ਚੋਪ | ಟೆಡ್ ಚೊಪ್ | ටෙඩ් චොප් | တက် ချော့ပ် | តេដ ឆប | ꦠꦺꦢ꧀ ꦕꦺꦴꦥ꧀ | ᬢᭂᬤ᭄ ᬘᭀᬧ᭄ | ᜆᜒᜇ᜔ ᜆ᜔ᜐᜓᜉ᜔ | ᏖᏗ ᏣᏊ | ꄊꄮ ꍏꀠ | ଟେଡ୍ ଚୋପ୍ | ⵜⴻⴷ ⵛⵓⵒ | 𐐓𐐯𐐼 𐐟𐐙𐐱𐐹 | 𐑑𐑧𐑛 𐑗𐑪𐑐 | 𐘳𐘂𐘅 𐘳𐘴𐘞 | 𐠔𐠁𐠊 𐠔𐠷𐠡 | 𐊗𐊁𐊅 𐊗𐊐𐊓 | 𐊴𐊭𐊺 𐊴𐋄𐊸 | 𐢞𐢉𐢅 𐢞𐢝𐢘 | ࠕࠄࠃ ࠕࠔࠐࠐ | 𐫤𐫏𐫝 𐫤𐫘𐫖 | ꡈꡦ ꡐꡡꡌ | ꯇꯦꯗ ꯆꯣꯄ | ꨓꨯꨕ ꨌꨱꨚ | ᨲᩮᨯ᩠ ᨩᩮᩫ᩠ | ꪔꫀꪒ ꪊꪮꪚ | ᯖᯩᯑ᯲ ᯙᯬᯇ᯲ | ꥆꥍꤴ ꥓ꥏꥒ | ᨈᨙᨉᨛ ᨌᨚᨄᨛ | ᮒᮨᮓ᮪ ᮎᮧᮕ᮪ | ᜦᜒᜇ᜴ ᜰᜳᜉ᜴ | ᝆᝒᝇ ᝌᝓᝉ | ꠔꠦꠖ ꠌꠥꠙ | 𑂞𑂵𑂠 𑂒𑂷𑂣 | 𑆠𑆼𑆢𑇀 𑆖𑆾𑆥𑇀 | 𑚔𑚵𑚖 𑚏𑚴𑚞 | 𑲌𑲏 𑱰𑱱 | 𑊢𑋐𑊦 𑊓𑋒 | 𑈋𑈸𑈍𑈴 𑈑𑈺𑈞𑈴 | 𑅐𑅬𑅒 𑅘𑅛 | 𑘝𑘿𑘟 𑘓𑘽𑘨 | 𑜔𑜦𑜕 𑜒𑜩𑜞 | 𑣕𑣈𑣙 𑣌𑣏𑣗 | 𞠔𞠀𞠙 𞠌𞠁𞠖 | 𑫎𑫟𑫒 𑫏𑫝𑫐 | 𐓰𐒰𐓈 𐓍𐒷𐓄 | 𞤚𞤫𞤣 𞤷𞤮𞥄 | 𖫐𖫪𖫓 𖫗𖫩𖫞 | 𛰙𛱎𛰣 𛲄𛱖𛱐 | ","biography":["I'm **Ted Tschopp**, a Senior Enterprise Architect based in Los Angeles, working at the intersection of **enterprise architecture, artificial intelligence, software strategy, and digital automation**.","At **Southern California Edison**, I help shape the architecture strategy for AI, software, and enterprise products that support one of the nation’s largest electric utilities. My work sits where **strategy meets execution**: platforms, guardrails, operating models, governance, risk, developer experience, and the practical realities of making ambitious technology useful, resilient, and sustainable inside a large organization.","I've spent **25+ years at SCE** helping teams navigate complex technology change. The part of enterprise architecture I care about most is not the diagram. It is the design discipline that makes systems usable, governable, sustainable, and welcoming for the people who depend on them and the teams who build them.","Before joining Edison, I owned a business featured in *Wired Magazine*, founded one of the largest J.R.R. Tolkien community websites, and worked in automotive market research. That mix of technology, storytelling, community-building, and analysis still shapes how I think about systems today.","I love working in technology because it lets me watch the future arrive in real time. Some of the things I have worked on were science fiction when I was in school. Now they are platform problems, governance problems, people problems, and architecture problems — which is where the interesting work begins.","Unless otherwise stated, everything here reflects my own views."],"email":"ted@tschopp.org","phonenumber":null,"keybaseio_username":"tedtschopp","twitter_username":"TedTschopp","twitter":"TedTschopp","github_username":"TedTschopp","linkedin_username":"tedtschopp","facebook_username":"ted.tschopp","google_username":"TedTschopp","youtube_username":"TedTschopp","pinterest_username":"TedTschopp","reddit_username":"tedtschopp","instagram_username":"tedtschopp","quora_username":"Ted-Tschopp","indiewebcamp_username":"Www.tedt.org","mastodon_username":"TedT@twit.social","mastodon_user_id":109286944787814808,"threads_username":"TedTschopp@threads.net","same_as":["https://www.linkedin.com/in/tedtschopp","https://github.com/TedTschopp","https://twit.social/@TedT","https://bsky.app/profile/tedt.org","https://twitter.com/TedTschopp","https://www.youtube.com/channel/UC4Q8pXroTVyXrIxg2u82pwg"],"knows_about":["Enterprise architecture","Enterprise artificial intelligence","AI governance","Software and platform strategy","Digital automation","Technology-enabled organizational change","Digital communities and storytelling","Swiss folklore","Tabletop role-playing game design"],"works_for":{"name":"Southern California Edison","url":"https://www.sce.com/"}}}, { "id": "https://tedt.org/slides/ai-strategy-discussion-starters/", "title": "AI Strategy Discussion Starters", "summary": "\n", "content_text": "", "content_html": "", "url": "https://tedt.org/slides/ai-strategy-discussion-starters/", "image": "/slides/decks/ai-strategy-discussion-starters/slide-preview.png", "date_published": "2026-07-27T00:00:00-07:00", "date_modified": "2026-07-27T00:00:00-07:00","author":{"name":"Ted Tschopp","url":"https://tedt.org/profile/","uri":"https://tedt.org/profile/","avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","givenname":"Ted","familyname":"Tschopp","othernames":"Þeodor Tʃopp | टेड चप | Фёдор Чоп | تد شُپ | Թեդ Չոպպ | Ted Çop | டெட் சாப் | טעד טשאָפּ | Τεντ Τσοπ | 테드 촙 | 特德·察普 | テッド・チョッパ | ტედ ჩოპი | เท็ด ชอพ | ເທດ ຊອບ | ടെഡ് ചോപ്പ് | টেড চপ | ཏེཌ་ ཅོཔ། | ቴድ ቾፕ | ᏖᏗ ᏦᏇ | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | 𐌀𐌄𐌃 𐌕𐌔𐌂𐌏𐌐𐌐 | Ⱅⰵⰴ ⱌⱁⱂⱂ | ܬܝܕ ܟܘܦ | ᠲᠡᠳᠡᠳ ᠴᠣᠫ | ᑌᑎ ᒍᐳᐱ | ꕚꔳ ꗍꖛ | ߕߋߘ ߞߐߔߔ | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐎚𐎄𐎆 𐎚𐎌𐎒𐎒 | 𐎄𐎓𐎆 𐎚𐎔𐎒𐎒 | 𐤕𐤄𐤃 𐤕𐤔𐤐𐤐 | 𐤕𐤃𐤄 𐤕𐤔𐤏𐤐 | 𐎚𐎄𐎆 𐎚𐎘𐎔𐎔 | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | 𓏏𓂧𓂝 𓏏𓊃𓍿𓊪 | ⲧⲉⲇ ⲧϣⲟⲡⲡ | 𐌕𐌄𐌃 𐌕𐌔𐌎𐌐𐌐 | 𐤈𐤃𐤄 𐤈𐤔𐤐𐤐 | 𐌕𐌄𐌃 𐌕𐌔𐌏𐌐𐌐 | 𐌕𐌄𐌃 𐌕𐌔𐌐𐌐 | 𐎄𐎕𐎆 𐎚𐎑𐎔𐎔 | 𐔓𐔖𐔆 𐔓𐔀𐔚𐔚 | 𐀳𐀂𐀅 𐀳𐀴𐀞 | 𐱃𐰀𐰓 𐱃𐰴𐰯 | 𑀢𑁂𑀤𑁆 𑀘𑁄𑀧𑁆 | 𐨟𐨂𐨡 𐨖𐨎𐨿 | 𐦚𐦱𐦟 𐦚𐦷𐦣 | 𐭓𐭐𐭃 𐭓𐭱𐭕𐭕 | 𐭲𐭩𐭣 𐭲𐭱𐭯𐭯 | ᚈᚓᚇ ᚈᚄᚉᚑᚚᚚ | 𒋼𒁺𒁍 𒋼𒊭𒉺𒉺 | ᛏᛖᛞ ᛏᛋᚲᛟᛈᛈ | تيد تشوب | ટેડ ચોક્પ | ਟੇਡ ਚੋਪ | ಟೆಡ್ ಚೊಪ್ | ටෙඩ් චොප් | တက် ချော့ပ် | តេដ ឆប | ꦠꦺꦢ꧀ ꦕꦺꦴꦥ꧀ | ᬢᭂᬤ᭄ ᬘᭀᬧ᭄ | ᜆᜒᜇ᜔ ᜆ᜔ᜐᜓᜉ᜔ | ᏖᏗ ᏣᏊ | ꄊꄮ ꍏꀠ | ଟେଡ୍ ଚୋପ୍ | ⵜⴻⴷ ⵛⵓⵒ | 𐐓𐐯𐐼 𐐟𐐙𐐱𐐹 | 𐑑𐑧𐑛 𐑗𐑪𐑐 | 𐘳𐘂𐘅 𐘳𐘴𐘞 | 𐠔𐠁𐠊 𐠔𐠷𐠡 | 𐊗𐊁𐊅 𐊗𐊐𐊓 | 𐊴𐊭𐊺 𐊴𐋄𐊸 | 𐢞𐢉𐢅 𐢞𐢝𐢘 | ࠕࠄࠃ ࠕࠔࠐࠐ | 𐫤𐫏𐫝 𐫤𐫘𐫖 | ꡈꡦ ꡐꡡꡌ | ꯇꯦꯗ ꯆꯣꯄ | ꨓꨯꨕ ꨌꨱꨚ | ᨲᩮᨯ᩠ ᨩᩮᩫ᩠ | ꪔꫀꪒ ꪊꪮꪚ | ᯖᯩᯑ᯲ ᯙᯬᯇ᯲ | ꥆꥍꤴ ꥓ꥏꥒ | ᨈᨙᨉᨛ ᨌᨚᨄᨛ | ᮒᮨᮓ᮪ ᮎᮧᮕ᮪ | ᜦᜒᜇ᜴ ᜰᜳᜉ᜴ | ᝆᝒᝇ ᝌᝓᝉ | ꠔꠦꠖ ꠌꠥꠙ | 𑂞𑂵𑂠 𑂒𑂷𑂣 | 𑆠𑆼𑆢𑇀 𑆖𑆾𑆥𑇀 | 𑚔𑚵𑚖 𑚏𑚴𑚞 | 𑲌𑲏 𑱰𑱱 | 𑊢𑋐𑊦 𑊓𑋒 | 𑈋𑈸𑈍𑈴 𑈑𑈺𑈞𑈴 | 𑅐𑅬𑅒 𑅘𑅛 | 𑘝𑘿𑘟 𑘓𑘽𑘨 | 𑜔𑜦𑜕 𑜒𑜩𑜞 | 𑣕𑣈𑣙 𑣌𑣏𑣗 | 𞠔𞠀𞠙 𞠌𞠁𞠖 | 𑫎𑫟𑫒 𑫏𑫝𑫐 | 𐓰𐒰𐓈 𐓍𐒷𐓄 | 𞤚𞤫𞤣 𞤷𞤮𞥄 | 𖫐𖫪𖫓 𖫗𖫩𖫞 | 𛰙𛱎𛰣 𛲄𛱖𛱐 | ","biography":["I'm **Ted Tschopp**, a Senior Enterprise Architect based in Los Angeles, working at the intersection of **enterprise architecture, artificial intelligence, software strategy, and digital automation**.","At **Southern California Edison**, I help shape the architecture strategy for AI, software, and enterprise products that support one of the nation’s largest electric utilities. My work sits where **strategy meets execution**: platforms, guardrails, operating models, governance, risk, developer experience, and the practical realities of making ambitious technology useful, resilient, and sustainable inside a large organization.","I've spent **25+ years at SCE** helping teams navigate complex technology change. The part of enterprise architecture I care about most is not the diagram. It is the design discipline that makes systems usable, governable, sustainable, and welcoming for the people who depend on them and the teams who build them.","Before joining Edison, I owned a business featured in *Wired Magazine*, founded one of the largest J.R.R. Tolkien community websites, and worked in automotive market research. That mix of technology, storytelling, community-building, and analysis still shapes how I think about systems today.","I love working in technology because it lets me watch the future arrive in real time. Some of the things I have worked on were science fiction when I was in school. Now they are platform problems, governance problems, people problems, and architecture problems — which is where the interesting work begins.","Unless otherwise stated, everything here reflects my own views."],"email":"ted@tschopp.org","phonenumber":null,"keybaseio_username":"tedtschopp","twitter_username":"TedTschopp","twitter":"TedTschopp","github_username":"TedTschopp","linkedin_username":"tedtschopp","facebook_username":"ted.tschopp","google_username":"TedTschopp","youtube_username":"TedTschopp","pinterest_username":"TedTschopp","reddit_username":"tedtschopp","instagram_username":"tedtschopp","quora_username":"Ted-Tschopp","indiewebcamp_username":"Www.tedt.org","mastodon_username":"TedT@twit.social","mastodon_user_id":109286944787814808,"threads_username":"TedTschopp@threads.net","same_as":["https://www.linkedin.com/in/tedtschopp","https://github.com/TedTschopp","https://twit.social/@TedT","https://bsky.app/profile/tedt.org","https://twitter.com/TedTschopp","https://www.youtube.com/channel/UC4Q8pXroTVyXrIxg2u82pwg"],"knows_about":["Enterprise architecture","Enterprise artificial intelligence","AI governance","Software and platform strategy","Digital automation","Technology-enabled organizational change","Digital communities and storytelling","Swiss folklore","Tabletop role-playing game design"],"works_for":{"name":"Southern California Edison","url":"https://www.sce.com/"}}}, { "id": "https://tedt.org/The-IT-Adaptive-Factory/", "title": "The IT Adaptive Factory", "summary": "Overnight an automated system that is scanning all your code for security problems identifies a newly disclosed vulnerability. The artificial intelligence system immediately generates a fix, opens a pull request, and notifies the relevant team members. This patch, which addresses the vulnerability, is ready for review before anyone has had their morning coffee.
Forty-seven files changed. Those changes are in the authenticaion service, the shared library where the user roles are defined, and an old deployment script. The agent even created a test harness to verify the changes. Documentation was updated automatically as well.
When the team gets in, they find that much of the work has already been done. The automated system has prepared the code for review, run initial tests, and updated the documentation.
Except the team has not modernized their code base. The automated system followed industry best practices, but the team had not kept up. They had always been meaning to refactor and update their code, but it had never gotten to be a priority above day-to-day firefighting and product owner needs. They don’t have a devops pipeline. The testing is done by another team. And because this is a change in how users are logging in and roles are applied to the system the impact ripples through multiple layers, requiring careful coordination and review by the whole development team.
The team is stuck, you see that vulnerability is a zero day exploit that is actively being used in the wild, and their system, their users, and their company is vulnerable. The urgency is palpable, yet the path forward is obstructed by the very technical debt and organizational constraints that have accumulated over time. The tension between immediate security needs and long-term modernization goals creates a high-stakes environment where every decision carries significant risk.
Now if this were a one off, every one in a while problem, the team could manage this with crunch (Crunch refers to a period of intense work, often involving long hours and high pressure, typically used to meet a critical deadline.).
But we are now entering into an era where this will become a frequent and unavoidable challenge, requiring organizations to rethink how they manage both immediate security threats and long-term technical debt.
Organizations will need to figure out how to offensively use AI to not only address immediate security threats but also to proactively manage and reduce technical debt over time.
This scene tells us more about the limitations of AI in isolation. AI removes one constraint and exposes the next one. The queue moves from typing to task definition, then to review, integration, specification, and eventually governance. While AI can handle specific tasks efficiently, the broader context of technical debt, organizational processes, and coordination requirements still dictates the overall pace and effectiveness of software delivery that organizations must use AI to buy down quickly.
I approached the same problem from two directions in Running to Stay Put and Beyond the Light Bulb. The first article looked at the Red Queen problem: a company can invest heavily, improve locally, and still remain in the same relative position because the same capabilities spread across the market. The second looked at the light-bulb stage of adoption, where AI is added to existing work while the shape of the work stays mostly intact.
An AI-driven IT factory is where those arguments become an operating model. The model is one component. The factory includes the work request, repository, build system, tests, release path, permissions, logs, governance, rollback, and the people who decide what may ship.
The factory metaphor emphasizes that software delivery is a complex, interconnected system where each component must function correctly for the whole to succeed. AI can optimize individual tasks, but the overall efficiency depends on how well the organization integrates AI into its broader processes and governance structures.
This maturity guide uses a Level 0 foundation with five steps above it. It measures how much implementation responsibility the organization can hand to AI while keeping ownership of the outcome. Human work moves away from direct code production and toward direction, specification, evaluation, exception handling, and control. Each step trades one bottleneck for another.
If you are coming to this article from the point of view of a developer accustomed to artisanal software development, the transition to an AI-driven IT factory may seem antitechtical on one hand or both exciting and daunting. You are used to having direct control over every line of code, every design decision, and every deployment. The idea of delegating significant portions of this work to AI can feel like relinquishing control, even as it promises to accelerate delivery and reduce repetitive tasks.
The IT industry is not a religious organization, cult, or unchanging guild. It is a place where value is created using the latest techniques and approaches. Many of us no longer program solutions using 1’s and 0’s. Many of us no longer write in assembly. Many of us no longer write in C or Cobol. Many of us now rely on higher-level languages, frameworks, and deterministic knowledge graphs to do activities like auto complete.
I have said a lot about this already in another article titled Artisanal Software Craftsman. I will not be addressing this transition here. But it is important to recognize that the shift from artisanal development to an AI-driven IT factory involves changes in mindset, processes, and the role of human developers.
Level 0 is called spicy autocomplete. The name is funny because it is accurate. The developer writes the software, and the AI predicts a line, a block, or a familiar function. It saves keystrokes. It can also create the feeling that the whole delivery system has accelerated when only the typing has changed.
A team can measure this badly. It can count accepted suggestions, generated lines, or hours that developers believe they saved. None of those numbers tells us whether lead time fell, whether review became easier, or whether production defects changed. A developer may finish a function twelve minutes earlier and then wait four days for an environment.
Level 0 works when developers treat every suggestion as untrusted code. They understand it, run local checks, and review it in proportion to the risk. A team is ready to move when developers can describe the likely solution before asking for one and can explain the code after accepting it.
Level 1 turns the assistant into a coding intern. The developer can delegate a bounded task: add a validation rule, write a unit test, refactor one module, or fix a narrow defect. The developer supplies the architecture and stays close to the result.
The quality of the request begins to matter here. “Clean up this service” gives the machine room to guess. “Remove the duplicate date conversion in these two methods, preserve the public interface, and run these four tests” gives it a job.
The most common Level 1 failure is quiet expansion. A small task spreads into unrelated files because the agent found a locally convenient path. The diff still looks plausible. The tests may even confirm the assumptions used to write the code. The reviewer has to ask whether the test proves the requested behavior, not whether the generated implementation agrees with itself.
Level 1 reduces more typing. The developer still has to do everything else they use to do manually.
Level 2 lets the AI navigate a repository and make a change across several modules. It can follow dependencies, update tests, and assemble a feature that no longer fits inside one file.
The productivity story becomes uncomfortable here, as it did in the introductory story.
Suppose an agent finishes in forty minutes what used to take a developer two days. The pull request touches thirty-seven files. The senior engineer who understands the service boundary needs most of a day to review it. A second reviewer checks security assumptions. The test team finds that the new code works in isolation and breaks a downstream batch process.
The forty-minute implementation consumed a day of senior review and another test cycle.
Review capacity becomes the scarce resource. Senior engineers can turn into permanent inspection stations for machine-produced work. Pull requests get larger because generation is cheap. Approvals get thinner because attention is expensive. Architecture starts to erode through small, reasonable-looking decisions: a new cross-module import, a copied rule, an internal type leaking through a public interface.
The guardrails against this behavior are that a Level 2 repository has clear architectural boundaries within the software itself, tests at service or feature edges, and automated checks that catch security and maintainability problems before a person opens the pull request. The reviewers still need enough system knowledge to spot a change that compiles cleanly while violating the design.
Another way to say this is a robust software architecture plan that is well-documented, consistently enforced, and supported by automated checks to ensure compliance throughout the development process. Most internally developed products do not have this as they rely on the tribal knowledge of the team working on the product.
A team should stay at Level 2 when its senior engineers are already buried. A good way to determine if a teams senior engineers are overwhelmed is to see if they are spending most of their time doing quality reviews instead of designing and guiding the overall architecture. Another key indicator is to measure the number of products an individual senior engineer is responsible for. If you find that senior engineers are consistently overloaded, it is a sign that the team can not move beyond Level 2. Giving the agent larger work items will create larger review debt.
Most organizations, product teams, and engineering groups I am familiar with will find themselves operating at Level 2 only on the best of days until senior leadership within the company does something to address this.
Level 3 is the management turn. The agent receives a feature-sized work item and returns a pull request or completed work package. The developer directs the work, reviews the evidence, and decides whether to accept it, reject it, or send it back.
That last option matters. Generated work has almost no emotional claim on the team. A person may feel awkward discarding another person’s week of effort. There is no reason to preserve an agent’s afternoon because it used a lot of tokens. Bad work should be deleted without ceremony.
This pull request becomes the unit of management at this level. A useful one carries the original request, an implementation summary, the unit, contract / integration, ui/usability tests that ran (and their results), known limits on the non-functional requirements, and any architecture or security decision that changed. Reviewers need to judge feature behavior and system impact. Line-by-line reading remains available for code that carries unusual risk, but it cannot be the only control.
This means that your AI agent needs to do more than just generate code. It must understand the context of the request, follow the architectural guidelines, write and run the necessary tests, and provide evidence of compliance with non-functional requirements.
Accountability gets slippery here. “The agent wrote it” explains the source of the requested change. It does not identify the owner. The person who approves the change owns the accepted behavior, and the product team owns what happens after release.
The surrounding agent system now matters as much as the model. Repository permissions, branch rules, test commands, tool access, time limits, and stop conditions live in the harness and delivery platform. I explored that larger system in The AI Value Stream.
The challenge you will have with level 3 is: how many people on the product team can properly review and manage pull requests today? How many can effectively make architectural decisions and enforce design consistency? How many can balance the immediate feature needs with long-term system health? How many can know when to accept work and reject it? How many can understand the full context and implications of the changes being proposed? The teams that succeed at level 3 are those who freed up their Lead Engineers in the previous step and who turned all their product team members into capable reviewers and managers of generated work.
Level 3 is stable only when feature requests have written acceptance criteria, the pipeline catches common agent errors, rollback remains practical, and rejection is a normal engineering outcome.
Level 4 changes the primary artifact. The human writes the specification. The AI performs the implementation. The team evaluates the result through behavior, evidence, and operating limits.
A vague user story is dangerous here. Consider the request, “Let customers change their mailing address.” A human team can fill in missing details through conversation and habit. An agent will also fill in the missing details, but it may choose answers by surveying all its training data and picking the most common path through the problem. A path that doesn’t differentiate between similar but distinct cases. A path that ignores edge cases and unique business rules. In other words a path that may satisfy the letter of the request but fail to meet business need.
A usable specification has to say who may request the change, which addresses are allowed, what records must stay synchronized, how identity is verified, which notices are required, what happens during an outage, and how the change is reversed. It also has to state what the new capability must leave alone. Those details used to live in meetings, old tickets, experienced people’s memories, and code review comments. Level 4 forces them into the work request.
The controls move earlier. Scenario tests are written before implementation. Edge cases are chosen before the builder sees the evaluation set. External systems are represented by sandboxes, mocks, simulators, or test tenants. The release evidence shows why the team accepted the outcome.
Visible tests are insufficient on their own. An agent can optimize for them and still miss the customer need. A test that checks whether a database row changed may pass while the notification, downstream billing update, or authorization rule is wrong. Holdout scenarios help because the builder cannot tailor the implementation to every check it will face.
I have observed that teams often underestimate the effort required to produce a truly executable specification. It is not enough to write down the desired behavior; one must also anticipate the edge cases, define the evaluation criteria, and ensure that the necessary test infrastructure is in place before implementation begins. I have written on this topic in How to Communicate in a World of AI.
The effort required to produce an executable specification is non-trivial and often underestimated. It will require that the product team work with their product owner and the team that supports them in their day to day job in the business to get all their subject matter experts up to speed on how to communicate an effective set of needs. The product team’s sphere of influence and transformation now extends into the business.
By Level 4, weak requirements become deployed defects, therefore they must be governed before they even get into the IT system. Specification quality and evaluation quality set the ceiling for delivery quality.
A dark factory is a manufacturing facility that can operate without continuous human presence, relying on automation, robotics, sensors, artificial intelligence, and autonomous control systems to produce goods.
A dark IT Factory is an IT delivery environment that functions like a dark factory producing physical goods. Humans primarily define business intent, establish governance, review exceptions, and improve the platform rather than manually performing each development task. A specification enters the factory. Agents plan the work, change code in an isolated environment, run tests, face scenario checks, and prepare a release. Policy gates decide whether the change can move. Production telemetry watches the result. The system retains enough evidence to reconstruct what the agents saw, which tools they used, what checks passed, who authorized the release, and what happened afterward.
This level requires narrow boundaries. The factory needs a named set of repositories, systems, product areas, and release types. It needs a list of people or systems allowed to submit work. Every external dependency needs containment. Automatic stop conditions have to be explicit. Release approval and rollback paths have to work under pressure. Quality, cost, latency, failures, and incidents need continuous monitoring.
The main risk is loss of trust. One unexplained production incident can discredit the entire approach. Weak specifications that are accepted accumulate as a new kind of technical debt. Missing scenarios hide risk until the factory meets a case nobody modeled. Broad permissions can turn a coding error into a customer or data incident. Unbounded runs can burn money while producing duplicate work. The temptation to leaders in the organization is that they will want to hollow out its own technical bench leading to circumstances where too few people still understand how the factory produces the product and how it behaves.
A Level 5 factory has to keep proving that it builds the intended thing, stops at the right boundary, leaves an audit trail, and can be disabled or rolled back. People still need to understand the product and its failure modes.
That idea is the practical side of Making AI Boring on Purpose. A normal factory run should be uneventful. The work enters through a known door, follows a controlled path, and leaves evidence behind. Nobody should need a heroic engineer to explain why the release happened.
The maturity model is clean on paper. Enterprise software is rarely clean. So what do you do when faced with a legacy system that does not fit neatly into the levels?
An old application may have a requirements document, but its actual specification is scattered across stored procedures, configuration tables, production data, support tickets, release scripts, and the memory of the person everyone calls when month-end processing fails.
That system cannot jump to Level 4 because a coding agent can read whats in the repository. The organization first has to recover what the system does and document it. Completely. AI can help trace code paths, summarize dependencies, compare documentation with behavior, and propose tests. It may even be able to write all that down someplace for referencing later. But the work still needs maintainers and product owners who can tell the difference between an accidental quirk of their system, a mistake made by the AI and a business rule that customers depend on.
For most brownfield systems, I would use Levels 1 and 2 for bounded maintenance and software archaeology. Teams can document observed behavior and build scenario tests around it. New components can move toward Levels 3 and 4 once their boundaries are understood. Level 5 belongs in contained areas where rollback is real and the evidence is strong.
This part will feel slow because it is slow. Fifteen years of allowing teams to proceed with exceptions from standards do not become a specification after one repository scan. You have 15 years of accumulated decisions and work to dig youself out from under. All the while while trying to catch up with the new system. A model can generate a new service in an afternoon. Recovering the decisions buried in the old one takes longer.
The maturity guide changes roles before it removes them. That distinction matters because software organizations have always developed judgment through work.
A junior developer used to learn by fixing defects, writing small features, and having a senior engineer explain what was wrong. When an agent takes much of that work, the junior still needs practice. The apprenticeship has to include task framing, review, debugging, test interpretation, system behavior, and the ability to explain generated code.
Senior engineers spend less time producing routine implementations and more time deciding what should exist, where the boundaries belong, and what evidence is enough. Testing specialists on the team design scenarios that a builder cannot easily game. DevOps and SRE specialists on the team own containment, permissions, rollback, cost controls, and runtime safety. Product Owners become specification owners. Architects design where autonomy is allowed and how responsibility moves through the system.
I made the broader people argument in AI Is a People Change. The factory will fail if the organization treats people as spare parts and assumes judgment will somehow replenish itself.
The apprenticeship question should be part of the architecture for the product. Who learns to debug the system when routine debugging is automated? Where do people practice judgment before they receive authority? How does an expert turn tacit knowledge into rules, examples, and exception paths that others can use?
A factory that produces software faster than it produces people who understand the software is like ripe fruit on the vine, its good for today, but tomorrow it spoils.
Maturity models become dangerous when leaders turn them into scoreboards. A company declares itself Level 3. A business unit sets Level 5 as a target. A vendor delivers proof that it is a level 4 provider that can do the work. Everyone is ready. This is missing the point.
I have little patience for an enterprise maturity score with a decimal point. The guide gives a simpler rule: record the lowest level that describes the normal way the team works. Track it by product, repository, workflow, or team. Do not average a Level 4 digital service and a Level 0 legacy system into a corporate score with a decimal point. The number would look precise and explain very little.
A team should look at where they are at and their weaknesses. Work on getting good at the areas where they are weak. If they encounter a situation where review is weak, tests do not prove behavior, system boundaries are unclear, or nobody can name the owner of generated behavior. Then stop and get better. High production risk, uncertain costs, and weak security controls are also good reasons to wait and get better. The right target is the highest level the operating model can the team and the organization can support.
When doing a review I ask what level describes ordinary work, what evidence shows it is working, and where the queue moved after AI arrived. I would ask what breaks if generated-code volume doubles. I would ask who owns a failed change, how rollback works, and how junior engineers are gaining judgment. Those questions are less exciting than a demo. They are much closer to production.
The Red Queen part of this problem is unforgiving. Coding models keep improving. They are now at the point where they are better then humans at finding security problems you find in the smallest of businesses all the way to largest enterprises. This means that in order to even stay put, you need to be at level 3 to address the security patches you will need to refactor into your products. The timeline to get to that level is measured in months. This pace of patching will only increase as the models and cheaper. Up until now the only organizations that could afford to run these systems are large global enterprises, but today an advanced coding model can be run on hardware that will cost you under $200,000. This puts this within reach of 15% of the worlds population.
But this also means you don’t need to be a large global enterprise to leverage advanced coding models for patching software. Even the smallest organization can access these global models at a price of $40 a month per user to strengthen their approach.
My bet is that the durable organizations will build out a version of this factory model above. They will have a competitive advantage, and the difference will sit in the factory: the accumulated specifications, scenario libraries, system boundaries, permissions, release evidence, rollback paths, and operating history. Those assets let a company replace one model with another, replay known cases, compare results, and keep the process under control.
A new model can improve the engine. It cannot supply a missing owner, recover an undocumented business rule, or decide how much risk the organization is willing to accept.
When the next generation of coding agents arrives, one group will announce another pilot. The other will connect it to a factory that already knows how to judge the work.
I will cover how this model applies to other areas of enterprise AI adoption.
", "url": "https://tedt.org/The-IT-Adaptive-Factory/", "image": "/img/2026-07/AI-driven-IT-Factory.webp", "tags": ["ai-driven software development","adaptive IT factory","AI maturity model","software engineering","technical debt","operating model","engineering leadership","AI governance"], "date_published": "2026-07-26T00:00:00-07:00", "date_modified": "2026-07-26T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/A-letter-to-the-Artisanal-Software-Craftsman/", "title": "A Letter to the Artisanal Software Craftsman", "summary": "Less then a decade ago, a Software Developer was a programmer who created software through direct, personal engagement with the code. Their craft lies in the accumulated judgment, taste, discipline, and care they bring to the work: understanding the problem, shaping the architecture, writing each implementation, and refining the result through deliberate inspection. They still use the technology of programming languages, development environments, compilers, debuggers, libraries, frameworks, and automation—but retain human authorship and comprehension as the central means of production.
Their technique in using this technology (yes, those words are related) is the repeatable practice through which that craft is expressed: decomposition, abstraction, test-driven development, code review, refactoring, debugging, performance analysis, and careful use of documentation. The master craftsman embodies a production philosophy in which quality depends on the developer’s cultivated skill. Like other artisans, they value control, traceability, and intimate knowledge of the finished work.
The term technology is related to the term technique, by technique I mean a deliberate and repeatable way of doing something; the arrangement of actions, tools, timing, and attention that makes a result more likely. The English word arrived in the early nineteenth century through the French technique, initially referring especially to the practical methods of art and musical performance. Behind it lies the Greek technē: art, skill, craft, or a reasoned method of making and doing. That ancestry matters because technique did not originally mean a sterile procedure separated from creativity. It described practical knowledge embodied in action: not simply knowing that something should be done, but knowing how to bring it into being.
Today we most readily recognize technique in activities with visible physical performance: a pianist’s touch, a painter’s brushwork, a surgeon’s incision, an athlete’s movement, or a programmer’s approach to decomposing a problem. But technique also shapes less visible forms of work. There are techniques for listening without becoming defensive, asking questions that expose assumptions, structuring a meeting, calming a frightened child, diagnosing an incident, writing a useful prompt, reviewing a decision, transferring knowledge, and introducing organizational change. Even governance has technique: the sequence in which evidence is presented, the way exceptions are framed, and the design of feedback loops can determine whether governance improves decisions or merely slows them down. Technique is therefore not confined to the hand. It can be social, intellectual, emotional, organizational, or computational.
The term craftsman, is related to the term craft, and by craft I mean the disciplined ability to make something work well in the real world; not merely possessing knowledge, following instructions, or producing an object by hand. The word comes from the Old English cræft, which originally meant power, strength, or might. Its meaning expanded to include skill, dexterity, art, science, talent, and eventually a trade requiring specialized ability. Craft was therefore never limited to quaint handiwork. It described human capability: knowledge made practical, judgment developed through experience, and the power to turn intention into a reliable result.
That older meaning remains hidden inside many of the ways we use the word today. Craft can mean the practiced skill of a carpenter, writer, engineer, or performer; the collective members of a profession; the careful construction of an argument or strategy; and even the cunning required to achieve something indirectly. It also appears in statecraft, tradecraft, stagecraft, witchcraft, watercraft, aircraft, and spacecraft. These uses may seem unrelated, but each concerns the knowledgeable exercise of power within a particular medium—wood, language, politics, intelligence, perception, water, air, or space. Even modern labels such as “craft beer” invoke a promise that judgment, care, identity, and deliberate choices remain visible in the result.
Applied today, craft is not the opposite of automation, scale, standardization, or industrial production. It is what allows those things to be designed intelligently. As tools take over more of the physical production, craft moves upward: from personally performing every operation to shaping the environment, standards, feedback loops, and decisions through which good work can repeatedly emerge. This is how technology (from be base word technique which means the application of craft) evolves: it extends human capability by embedding judgment, skill, and experience into the tools and systems we create.
Software development is a craft. It rewards curiosity, judgment, discipline, taste, and deep knowledge of the systems being built. None of those qualities disappear when development becomes more industrial. Industrialization does not mean replacing thoughtful people with an assembly line. It means making the routine parts of the work repeatable, observable, testable, secure, and recoverable instead of depending on memory, manual effort, and heroics.
I understand why some people resist this change. They have seen automation programs used as excuses to eliminate jobs. They have been handed unreliable tools by leaders who did not understand the work. They have watched management celebrate generated code while ignoring the cost of reviewing, repairing, and operating it. Some are afraid that a profession they spent decades learning will be reduced to typing instructions into a machine. Those concerns are legitimate. They deserve honest answers, approved tools, meaningful training, protected time to learn, strong engineering controls, and a voice in how the factory is built.
But refusal is not a strategy.
In an enterprise, choosing not to use AI is no longer merely a personal preference about how someone likes to write code. It affects how quickly vulnerabilities are repaired, how long customers wait, how much work falls onto other team members, and how much the organization must spend to make a change. When safer and faster methods become available, continuing to rely on handcrafted procedures, tribal knowledge, manual testing, and heroic effort transfers the cost of that preference to everyone else.
No one should be expected to trust generated work blindly. AI should be questioned, bounded, tested, monitored, and audited. Skepticism is part of the job. There is an important difference, however, between refusing unsafe automation and refusing to learn how automation can be used safely. One is responsible engineering. The other eventually becomes an organizational liability.
The truth is that a developer who categorically refuses to work with AI will increasingly resemble an engineer who refuses a compiler, a PC as opposed to a mainframe, a modern programming language as opposed to C or Assembly, source control as opposed to a folder, automated testing as opposed to an externalized testing team, or continuous integration and deployment as opposed to manual deployment approved by giant teams of humans assessing each change. That engineer may still be talented. They may still produce excellent code. Their experience may remain enormously valuable. But an enterprise cannot base its future operating model on a method that does not scale with the growing volume, speed, and complexity of change.
Today I think many people confuse technique with craft. They see the steps and the tools and assume that following them is sufficient. But true mastery requires understanding the principles behind the methods and knowing when and how to apply them wisely.
Craft and technique do align, but they are not identical. Technique or technology is the method; craft is the cultivated judgment that governs the method. Technique tells a person the steps to follow to perform an operation, while craft tells them when that operation is appropriate, how carefully it must be performed, when it should be adapted, and when it should be abandoned altogether. A novice may reproduce a technique exactly, while a craftsperson understands the conditions that make it succeed or fail.
In modern times technology advances technique by automating many things. Computers may learn, generate, and execute many techniques, but craft remains visible in the framing of the problem, the selection of methods, the evaluation of results, and responsibility for consequences. Technique makes capable action repeatable; craft makes that action intelligent.
A profession does not preserve its dignity by preserving its bottlenecks.
The developer’s role is not becoming less important. It is becoming more demanding. Developers will be expected to define intent precisely, expose hidden assumptions with more clarity, design durable boundaries with more foresight, judge evidence wtih more rigor, anticipate failure earlier, understand production behavior during design, and decide when AI generated work must be rejected. The amount of human typing may decline. The amount of craft required will not.
Leaders have obligations in this transition as well. They cannot purchase an AI tool, announce a productivity target, and declare that transformation has occurred. They must provide safe platforms, clear policies, realistic workloads, training, apprenticeship, and room for people to make mistakes while learning. They must reward people for improving the system, not merely for producing more code. Compassion requires helping people cross the gap. It does not require pretending the gap can be ignored forever.
Artisanal development will continue to have a place. Exploration, experimentation, unusual algorithms, prototypes, small personal tools, and genuinely novel problems may all benefit from an individual craftsperson working close to the material. But artisanal development cannot remain the default operating model for critical enterprise systems. Systems that support customers, employees, infrastructure, money, safety, or regulated operations must be built and maintained through processes that can perform reliably without depending on a particular person having a good day.
People are not obsolete. The old division of labor is. We should carry the judgment, ethics, creativity, and hard-earned craft of software development into the new factory. We should help one another make that transition with patience and respect. We should also be unflinchingly clear that standing still is a decision—and in an environment changing this quickly, it is a decision to fall behind.
", "url": "https://tedt.org/A-letter-to-the-Artisanal-Software-Craftsman/", "image": "/img/2026-07/Artisanal-Software-Craftsman.webp", "tags": ["software craftsmanship","artisanal software development","AI-assisted development","software engineering","industrialization","operating model","engineering leadership","automation"], "date_published": "2026-07-26T00:00:00-07:00", "date_modified": "2026-07-26T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/Running-to-stay-put-the-Red-Queen-problem-in-enterprise-AI/", "title": "Running to Stay Put", "summary": "As an enterprise architect, I am used to target states. We describe the present and choose a destination. Then we plan the transitions between them. AI makes that habit uncomfortable. A target architecture approved this quarter can look dated before the funding clears. A vendor changes its model. A software product adds the feature we planned to build. A competitor cuts the time required to serve a customer. Employees adopt a different tool on their own.
\n", "content_text": "As an enterprise architect, I am used to target states. We describe the present and choose a destination. Then we plan the transitions between them. AI makes that habit uncomfortable. A target architecture approved this quarter can look dated before the funding clears. A vendor changes its model. A software product adds the feature we planned to build. A competitor cuts the time required to serve a customer. Employees adopt a different tool on their own.The Red Queen explains this pattern.What the Red Queen meansIn Through the Looking-Glass, Alice runs beside the Red Queen and discovers that all of the effort has left her in the same place. Leigh Van Valen borrowed the scene for evolutionary theory. His Red Queen hypothesis described a world in which a species’ environment includes other species that are adapting at the same time. A prey animal becomes harder to catch, so its predator must change. Both species may improve while their relative positions stay about the same.1I use Red Queen syndrome for the enterprise version of that pattern. Investment rises and local performance improves, yet the company’s relative position barely moves. A capability that saves money this year may become a normal cost of doing business next year. Customers absorb the improvement into their expectations. Competitors buy similar technology. Vendors place the same feature inside products that many firms already own.AI is unusually well suited to this pattern because its capabilities spread quickly. Model providers release a new function, software vendors package it, consulting firms repeat the implementation pattern, and employees bring the habit into work. Stanford’s 2026 AI Index puts organizational adoption at 88 percent. On SWE-bench Verified, reported performance rose from 60 percent to nearly 100 percent in a year. McKinsey’s 2025 survey found the same adoption rate, while only about one-third of respondents said their companies had begun to scale AI across the enterprise.2The gap matters. Almost every large company can point to AI work. Far fewer can point to a business process that now behaves differently from end to end.The Implementation Pattern in Large EnterprisesA common first move is a horizontal assistant. It drafts email, summarizes meetings, searches documents, and writes a first pass at analysis. Employees often save real time. The same assistant is available across the market. Within a short period, faster drafting becomes an expected part of office work. The company-specific difference is the assistant’s access to policy, role context, workflow state, and decision history.3A retrieval-augmented generation (RAG) project often comes next. The retrieval system sits over shared drives, intranet pages, ticket systems, and document repositories. Search gets faster. Then the harder problem arrives. Two policy documents disagree. The metadata is incomplete. A procedure has no owner. A business term means one thing in finance and another in operations. The AI has exposed a knowledge-management problem the organization has that the AI search project cannot solve until the leaders decide to fix the newly surfaced KM problem.Coding assistants can raise developer throughput. Product teams respond with larger backlogs. Security teams receive more risk assessments. Test suites grow. The maintenance inventory grows with them. A company gains little from producing code faster when test environments, release controls, product feedback from users, and operational responses to events remain slow.Contact-center AI can summarize a call and suggest a response. Those functions can reduce handle time and in many cases increase customer satisfaction initially; but customers judge the full resolution. A system that writes a polite answer but cannot correct a request, issue a refund, change an address, or schedule a visit has sped up one part of a queue and overwhelmed another. Once every major provider supplies fast summaries and suggested replies, the market’s response-time expectation drops and those investments that didn’t take the Red Queen into account in their ROI have just damaged themselves.Marketing teams can produce far more content with the same staff. Competitors can do the same. The supply of competent copy rises and customer attention becomes harder to earn. Brand trust, first-party customer knowledge, distribution access, and good commercial judgment continue to matter because a general model cannot buy them from a catalog.Agent programs bring the same issue into transactional work. McKinsey found that 23 percent of respondents were scaling an agentic system somewhere in the enterprise and another 39 percent were experimenting. Most companies that were scaling agents were doing so in one or two functions.4 An agent may coordinate a service request across several systems, which can be useful. Its business effect depends on the authority it receives and the quality of the process around it. It also depends on whether the company measures what happened after the agent acted, because if the next step after the Agent isn’t: “And the customers is satisfied with the way their request was fulfilled” has more work to do.Why the Pilot Count Climbs While the Economics LagLarge enterprises are good at funding small projects to with a visible sponsor and a clean demonstration. End-to-end process change crosses budget and organizational boundaries. It also reaches policy, job design, system ownership, and service commitments. The pilot therefore enters at the edge of the process, where approval is easier and never moves further. Today’s organizational structures and team compositions were designed to optimize for customer need fulfillment, coordination costs across boundaries, and their flexibility to manage this in an age without AI.So as ideas pile up and the use-case register overflows. Each entry can make sense on its own and in the world of yesterday. But across the portfolio, teams duplicate model gateways, retrieval stores, prompt libraries, and evaluation code. Business units buy overlapping assistants. The organization pays several times for similar capabilities and still lacks a common way to measure them; are customers who pay the company money getting their needs met, are coordination costs minimized, and can leadership manage with flexibility?McKinsey’s 2025 survey illustrates the problem. Thirty-nine percent of respondents attributed some enterprise Earnings Before Interest and Taxes (EBIT) effect to AI, and most of that group put the effect below 5 percent. The same research found a strong association between business impact and fundamental workflow redesign.5 The financial effect appears when the process changes to assume AI from the very beginning.Governance often carries the same mentality. A committee approves a use case at a point in time. After deployment, the model version changes, the system instructions change, source content changes, and the tool gains access to another action. The original approval assumed one set of risks but never considered about how each underlying subsystem would change each month.I have also become skeptical of the phrase “data moat.” Possession alone does very little. A million PDFs with uncertain ownership and conflicting definitions remain a million uncertain PDFs after a chatbot indexes them. Company data starts to matter when it improves a decision, otherwise it’s just extra processing waste. And when data is used to make a change in reality, the result must be recorded and used to change the next decision.How I Would Reshape the PortfolioFor every material AI use case, I would ask how common the underlying capability is and how deeply it changes a company-specific process.A meeting summarizer is common and shallow. I would treat it as table stakes. The company needs safe access and cost controls. A meeting summarizer does not distinguish a company for long.A claims assistant connected to policy, authority limits, claim history, and payment controls is different. The underlying model may still be common. The process integration is company-specific, and the outcome can be measured in cycle time or loss.Then there is the custom chatbot with no workflow authority. Large enterprises build many of these because they make good demonstrations. They are often expensive wrappers around a general model. The operating model survives untouched.Cases deep inside a process can produce feedback after use, but is the organization using it? Did the system capture it? Were users required to provide it? Once this data is collected, the next challange occurs; custom model training is always modest at first. The asset is the grows with inputs, decisions, exceptions, and outcomes. A competitor cannot acquire that record through a software license, and many times the enterprise refuses to spend the money to capture this while they are running.This view changes how I would fund the portfolio. Utilities need cost control, adoption support, shared security, and vendor management. Process work needs a business owner who can alter targets or capacity. A change to a customer offer needs revenue accountability. A research bet needs a loss limit and a date for the next decision. Each these are different things that require different metrics, processes, decisions, exceptions, and in the end, outcomes.The outcome should be named before the model is selected. A claims system should change elapsed time and leakage. A service system should change first-contact resolution and cost per resolved case. A coding assistant should change lead time, rework, escaped defects, and maintenance load. Is your enterprise capturing these metrics? If not, you need to include the costs of capturing these metrics in your Agent buildout.I have little patience for business cases that multiply minutes saved by every employee and call the result value. The calculation skips the hard part. Someone must change a capacity plan, a service level, a staffing assumption, or a queue rule. The person who is qualified to do this is someone the product owner which we can call a benefit owner.Architecture for a Moving TargetI would design the model as a replaceable dependency. I would design the prompts, skills, tools, and harnesses as replaceable dependencies that focus business context. However the actual business state stays in the workflow platform or system of record. The model receives the context required for a bounded task. It returns an output with enough trace information to evaluate what happened.A consequential action needs a record of the source material, the AI instructions, and the model version. The record should also retain the instruction, output, human override, and later outcome. That history supports incident review. It also makes model replacement possible because the company can replay known cases against a candidate model.Identity must follow every retrieval and every tool call. A conversational interface does not get extra access merely because it feels informal. The agent acts with a named identity, a defined scope, an expiration time, and a limit on what it can change. The workflow engine remains responsible for state, retries, compensation, and timeout behavior.Full vendor neutrality can create a low common denominator. Stable contracts should surround the business capability. Teams can then use a vendor-specific function deliberately when its benefit is worth the switching cost. Architecture decision records should state where that cost exists.Production evaluation belongs in normal operations. A launch score tells us how a system performed on yesterday’s cases. The running service needs sampling, failure review, cost monitoring, and outcome checks. NIST’s AI Risk Management Framework calls for risk tracking over time and for post-deployment plans that cover user input, appeal or override, decommissioning, incident response, recovery, and change management.6Governance Should Follow AuthorityRisk tiering should start with what the system can do.An internal drafting aid has a small blast radius. A recommendation used in a regulated decision has a larger one. An agent that writes to a system of record needs stronger identity controls, narrow authority, complete logs, and a tested rollback path.Autonomy can advance in steps. A system may read, draft, recommend, execute after approval, and execute within a narrow policy. Each step changes the evidence and controls required. A human reviewer needs enough time, access to the source material, authority to disagree, and a recorded reason for an override.The operating model needs a similar division of work. A central group owns shared contracts, platform services, identity patterns, and evaluation methods. Domain teams own the process outcome, exception rules, operating procedures, and user adoption. Risk and legal specialists join the work where the decision has consequence. They do not have to recreate a full review for every low-risk assistant.The finance side is simple to state and hard to do. Time saved becomes value after the company changes overtime, hiring, throughput, price, loss, or service capacity. A benefit owner chooses the conversion mechanism. The finance team checks whether the gain appeared. The measure is revisited after competitors reset price or service expectations.The workforce problem is easy to miss. When AI writes the first draft of an analysis, junior staff lose one of the ways they used to learn. Senior staff need to make the reasoning visible and review the work as both instruction and quality control. Role design should state where people practice judgment and how they gain authority over time. A company can increase output while its bench of experienced people gets thinner.A Claims ExampleConsider a large insurer that has deployed an office assistant, a coding copilot, call summaries, and a policy chatbot. Employees use them. Local measures improve. Other insurers have bought similar products, so the relative position changes very little.Now apply AI to the claims process itself.At intake, a model reads the submitted form and photographs. A retrieval service fetches the applicable policy language and records the source. Business rules establish authority limits. A fraud model adds its score without deciding the claim. The adjuster receives the source evidence, the model’s uncertainty, the applicable authority, and the next action permitted by policy.An agent can request a missing document or schedule an inspection. Payment remains under the controls of the claims platform. Exceptions return to a person with the case history intact. Every action is logged under an identity.The program measures elapsed time, reopened claims, leakage, complaint rate, and human overrides. Closed claims become evaluation cases when their outcomes are known. The team can see where the model helps and where it adds noise. It can also find policy ambiguity and process defects.The foundation model is widely available. The insurer’s policy interpretation, exception history, operating rules, and measured claim outcomes belong to the insurer. Those assets improve through use. A model can be replaced while the claims capability remains.What I Would Ask at the Next Architecture ReviewA crowded roadmap tells me that a company is active. It says little about relative progress.I would ask what work changed, what result moved, what can be replaced, and what the company learned. I would ask who owns the benefit after deployment. I would ask how the system fails and how the team knows.Much of the AI portfolio is ordinary modernization. That work keeps employee tools and unit costs near the market baseline. A smaller set of investments can change the company’s position by reaching into a process and producing evidence for the next decision.When the answers are licenses, active users, prompt counts, and polished demonstrations, the organization is running, but the scenery is still in the same place. Springer ↩ Stanford HAI ↩ McKinsey & Company ↩ McKinsey & Company ↩ McKinsey & Company ↩ NIST AI Resource Center ↩ ", "content_html": "As an enterprise architect, I am used to target states. We describe the present and choose a destination. Then we plan the transitions between them. AI makes that habit uncomfortable. A target architecture approved this quarter can look dated before the funding clears. A vendor changes its model. A software product adds the feature we planned to build. A competitor cuts the time required to serve a customer. Employees adopt a different tool on their own.
The Red Queen explains this pattern.
In Through the Looking-Glass, Alice runs beside the Red Queen and discovers that all of the effort has left her in the same place. Leigh Van Valen borrowed the scene for evolutionary theory. His Red Queen hypothesis described a world in which a species’ environment includes other species that are adapting at the same time. A prey animal becomes harder to catch, so its predator must change. Both species may improve while their relative positions stay about the same.1
I use Red Queen syndrome for the enterprise version of that pattern. Investment rises and local performance improves, yet the company’s relative position barely moves. A capability that saves money this year may become a normal cost of doing business next year. Customers absorb the improvement into their expectations. Competitors buy similar technology. Vendors place the same feature inside products that many firms already own.
AI is unusually well suited to this pattern because its capabilities spread quickly. Model providers release a new function, software vendors package it, consulting firms repeat the implementation pattern, and employees bring the habit into work. Stanford’s 2026 AI Index puts organizational adoption at 88 percent. On SWE-bench Verified, reported performance rose from 60 percent to nearly 100 percent in a year. McKinsey’s 2025 survey found the same adoption rate, while only about one-third of respondents said their companies had begun to scale AI across the enterprise.2
The gap matters. Almost every large company can point to AI work. Far fewer can point to a business process that now behaves differently from end to end.
A common first move is a horizontal assistant. It drafts email, summarizes meetings, searches documents, and writes a first pass at analysis. Employees often save real time. The same assistant is available across the market. Within a short period, faster drafting becomes an expected part of office work. The company-specific difference is the assistant’s access to policy, role context, workflow state, and decision history.3
A retrieval-augmented generation (RAG) project often comes next. The retrieval system sits over shared drives, intranet pages, ticket systems, and document repositories. Search gets faster. Then the harder problem arrives. Two policy documents disagree. The metadata is incomplete. A procedure has no owner. A business term means one thing in finance and another in operations. The AI has exposed a knowledge-management problem the organization has that the AI search project cannot solve until the leaders decide to fix the newly surfaced KM problem.
Coding assistants can raise developer throughput. Product teams respond with larger backlogs. Security teams receive more risk assessments. Test suites grow. The maintenance inventory grows with them. A company gains little from producing code faster when test environments, release controls, product feedback from users, and operational responses to events remain slow.
Contact-center AI can summarize a call and suggest a response. Those functions can reduce handle time and in many cases increase customer satisfaction initially; but customers judge the full resolution. A system that writes a polite answer but cannot correct a request, issue a refund, change an address, or schedule a visit has sped up one part of a queue and overwhelmed another. Once every major provider supplies fast summaries and suggested replies, the market’s response-time expectation drops and those investments that didn’t take the Red Queen into account in their ROI have just damaged themselves.
Marketing teams can produce far more content with the same staff. Competitors can do the same. The supply of competent copy rises and customer attention becomes harder to earn. Brand trust, first-party customer knowledge, distribution access, and good commercial judgment continue to matter because a general model cannot buy them from a catalog.
Agent programs bring the same issue into transactional work. McKinsey found that 23 percent of respondents were scaling an agentic system somewhere in the enterprise and another 39 percent were experimenting. Most companies that were scaling agents were doing so in one or two functions.4 An agent may coordinate a service request across several systems, which can be useful. Its business effect depends on the authority it receives and the quality of the process around it. It also depends on whether the company measures what happened after the agent acted, because if the next step after the Agent isn’t: “And the customers is satisfied with the way their request was fulfilled” has more work to do.
Large enterprises are good at funding small projects to with a visible sponsor and a clean demonstration. End-to-end process change crosses budget and organizational boundaries. It also reaches policy, job design, system ownership, and service commitments. The pilot therefore enters at the edge of the process, where approval is easier and never moves further. Today’s organizational structures and team compositions were designed to optimize for customer need fulfillment, coordination costs across boundaries, and their flexibility to manage this in an age without AI.
So as ideas pile up and the use-case register overflows. Each entry can make sense on its own and in the world of yesterday. But across the portfolio, teams duplicate model gateways, retrieval stores, prompt libraries, and evaluation code. Business units buy overlapping assistants. The organization pays several times for similar capabilities and still lacks a common way to measure them; are customers who pay the company money getting their needs met, are coordination costs minimized, and can leadership manage with flexibility?
McKinsey’s 2025 survey illustrates the problem. Thirty-nine percent of respondents attributed some enterprise Earnings Before Interest and Taxes (EBIT) effect to AI, and most of that group put the effect below 5 percent. The same research found a strong association between business impact and fundamental workflow redesign.5 The financial effect appears when the process changes to assume AI from the very beginning.
Governance often carries the same mentality. A committee approves a use case at a point in time. After deployment, the model version changes, the system instructions change, source content changes, and the tool gains access to another action. The original approval assumed one set of risks but never considered about how each underlying subsystem would change each month.
I have also become skeptical of the phrase “data moat.” Possession alone does very little. A million PDFs with uncertain ownership and conflicting definitions remain a million uncertain PDFs after a chatbot indexes them. Company data starts to matter when it improves a decision, otherwise it’s just extra processing waste. And when data is used to make a change in reality, the result must be recorded and used to change the next decision.
For every material AI use case, I would ask how common the underlying capability is and how deeply it changes a company-specific process.
A meeting summarizer is common and shallow. I would treat it as table stakes. The company needs safe access and cost controls. A meeting summarizer does not distinguish a company for long.
A claims assistant connected to policy, authority limits, claim history, and payment controls is different. The underlying model may still be common. The process integration is company-specific, and the outcome can be measured in cycle time or loss.
Then there is the custom chatbot with no workflow authority. Large enterprises build many of these because they make good demonstrations. They are often expensive wrappers around a general model. The operating model survives untouched.
Cases deep inside a process can produce feedback after use, but is the organization using it? Did the system capture it? Were users required to provide it? Once this data is collected, the next challange occurs; custom model training is always modest at first. The asset is the grows with inputs, decisions, exceptions, and outcomes. A competitor cannot acquire that record through a software license, and many times the enterprise refuses to spend the money to capture this while they are running.
This view changes how I would fund the portfolio. Utilities need cost control, adoption support, shared security, and vendor management. Process work needs a business owner who can alter targets or capacity. A change to a customer offer needs revenue accountability. A research bet needs a loss limit and a date for the next decision. Each these are different things that require different metrics, processes, decisions, exceptions, and in the end, outcomes.
The outcome should be named before the model is selected. A claims system should change elapsed time and leakage. A service system should change first-contact resolution and cost per resolved case. A coding assistant should change lead time, rework, escaped defects, and maintenance load. Is your enterprise capturing these metrics? If not, you need to include the costs of capturing these metrics in your Agent buildout.
I have little patience for business cases that multiply minutes saved by every employee and call the result value. The calculation skips the hard part. Someone must change a capacity plan, a service level, a staffing assumption, or a queue rule. The person who is qualified to do this is someone the product owner which we can call a benefit owner.
I would design the model as a replaceable dependency. I would design the prompts, skills, tools, and harnesses as replaceable dependencies that focus business context. However the actual business state stays in the workflow platform or system of record. The model receives the context required for a bounded task. It returns an output with enough trace information to evaluate what happened.
A consequential action needs a record of the source material, the AI instructions, and the model version. The record should also retain the instruction, output, human override, and later outcome. That history supports incident review. It also makes model replacement possible because the company can replay known cases against a candidate model.
Identity must follow every retrieval and every tool call. A conversational interface does not get extra access merely because it feels informal. The agent acts with a named identity, a defined scope, an expiration time, and a limit on what it can change. The workflow engine remains responsible for state, retries, compensation, and timeout behavior.
Full vendor neutrality can create a low common denominator. Stable contracts should surround the business capability. Teams can then use a vendor-specific function deliberately when its benefit is worth the switching cost. Architecture decision records should state where that cost exists.
Production evaluation belongs in normal operations. A launch score tells us how a system performed on yesterday’s cases. The running service needs sampling, failure review, cost monitoring, and outcome checks. NIST’s AI Risk Management Framework calls for risk tracking over time and for post-deployment plans that cover user input, appeal or override, decommissioning, incident response, recovery, and change management.6
Risk tiering should start with what the system can do.
An internal drafting aid has a small blast radius. A recommendation used in a regulated decision has a larger one. An agent that writes to a system of record needs stronger identity controls, narrow authority, complete logs, and a tested rollback path.
Autonomy can advance in steps. A system may read, draft, recommend, execute after approval, and execute within a narrow policy. Each step changes the evidence and controls required. A human reviewer needs enough time, access to the source material, authority to disagree, and a recorded reason for an override.
The operating model needs a similar division of work. A central group owns shared contracts, platform services, identity patterns, and evaluation methods. Domain teams own the process outcome, exception rules, operating procedures, and user adoption. Risk and legal specialists join the work where the decision has consequence. They do not have to recreate a full review for every low-risk assistant.
The finance side is simple to state and hard to do. Time saved becomes value after the company changes overtime, hiring, throughput, price, loss, or service capacity. A benefit owner chooses the conversion mechanism. The finance team checks whether the gain appeared. The measure is revisited after competitors reset price or service expectations.
The workforce problem is easy to miss. When AI writes the first draft of an analysis, junior staff lose one of the ways they used to learn. Senior staff need to make the reasoning visible and review the work as both instruction and quality control. Role design should state where people practice judgment and how they gain authority over time. A company can increase output while its bench of experienced people gets thinner.
Consider a large insurer that has deployed an office assistant, a coding copilot, call summaries, and a policy chatbot. Employees use them. Local measures improve. Other insurers have bought similar products, so the relative position changes very little.
Now apply AI to the claims process itself.
At intake, a model reads the submitted form and photographs. A retrieval service fetches the applicable policy language and records the source. Business rules establish authority limits. A fraud model adds its score without deciding the claim. The adjuster receives the source evidence, the model’s uncertainty, the applicable authority, and the next action permitted by policy.
An agent can request a missing document or schedule an inspection. Payment remains under the controls of the claims platform. Exceptions return to a person with the case history intact. Every action is logged under an identity.
The program measures elapsed time, reopened claims, leakage, complaint rate, and human overrides. Closed claims become evaluation cases when their outcomes are known. The team can see where the model helps and where it adds noise. It can also find policy ambiguity and process defects.
The foundation model is widely available. The insurer’s policy interpretation, exception history, operating rules, and measured claim outcomes belong to the insurer. Those assets improve through use. A model can be replaced while the claims capability remains.
A crowded roadmap tells me that a company is active. It says little about relative progress.
I would ask what work changed, what result moved, what can be replaced, and what the company learned. I would ask who owns the benefit after deployment. I would ask how the system fails and how the team knows.
Much of the AI portfolio is ordinary modernization. That work keeps employee tools and unit costs near the market baseline. A smaller set of investments can change the company’s position by reaching into a process and producing evidence for the next decision.
When the answers are licenses, active users, prompt counts, and polished demonstrations, the organization is running, but the scenery is still in the same place.
What release cadence, benchmark progress, and a $149 billion quarter suggest about the next launches from OpenAI, Anthropic, Google, SpaceXAI, Meta, and nine fast-moving challengers.
The artificial intelligence industry is waiting for another dramatic naming moment: GPT-6, Gemini 4, Claude 6, Grok 5.
The data suggests that is the wrong thing to watch.
The next wave is more likely to arrive as a continuous sequence of model-family upgrades, agent-focused releases, faster inference tiers, open-weight systems, and production refinements. Some will carry major new numbers. Many will not. Collectively, however, they will change what enterprises can automate long before any single launch becomes the symbolic start of a new generation.
Two charts make that visible.
The first is the model frontier. In the benchmark history behind the accompanying chart, the best score available from each provider rises in steps rather than in a smooth line. OpenAI and Anthropic currently occupy the highest band, but SpaceXAI, Meta, Google, Z AI, Alibaba, DeepSeek, Kimi, MiniMax, and Xiaomi have compressed much of the field into a surprisingly narrow range. The market is no longer defined by one laboratory moving while everyone else waits.
The second chart is investment. Combined quarterly capital expenditure by Microsoft, Google, Meta, Amazon, Oracle, and Apple increased from approximately $39.4 billion in Q1 2021 to $149.4 billion in Q1 2026—nearly four times as much in five years. Amazon represented about 29% of the latest quarter, Google 24%, Microsoft 21%, Meta 13%, Oracle 12.5%, and Apple 1.3%. This is total corporate capital expenditure, not a clean measure of AI spending, but the direction is unmistakable: the infrastructure for training and serving the next model wave is already being built.
S&P Global Ratings estimates that the five major cloud providers could spend about $750 billion in 2026, or roughly 38% of their combined revenue. The release race is therefore not primarily constrained by ambition or access to capital. It is constrained by power, chips, data, safety validation, inference economics, and the ability to turn raw capability into dependable products.
That changes how we should forecast the next two to three quarters.
This is not an insider roadmap, and the dates below are estimates rather than announced commitments. I used four signals:
The result is best read as a set of probability windows. A precise model name is fragile. A direction of travel—more autonomous agents, longer context, stronger tool use, lower inference cost, and more specialized model tiers—is much more predictable.
Recent frontier announcements increasingly emphasize coding, computer use, tool orchestration, memory, and long-running work. OpenAI is positioning GPT-5.6 around professional and agentic tasks. Meta’s Muse Spark 1.1 combines multimodal reasoning, coding, computer use, and multi-agent workflows. Anthropic’s latest Claude releases emphasize longer autonomous operation. MiniMax, Xiaomi, Qwen, Kimi, Mistral, and Z AI are all telling similar stories.
The important benchmark will increasingly be completed work: Can the system plan, call tools, recover from errors, preserve state, and finish a multi-hour task within a cost and policy envelope?
OpenAI’s Sol, Terra, and Luna tiers are a clear example. Providers can advance capability, latency, and price independently rather than forcing every improvement into one monolithic release. Google, Anthropic, DeepSeek, Qwen, and Mistral are following comparable portfolio strategies.
This means the most consequential near-term release may be a cheaper or faster tier that makes an existing capability economically deployable—not the model with the highest benchmark score.
Several recent systems now advertise context windows near one million tokens. Context length still matters, but the competitive question is shifting from how much a model can ingest to how reliably it can reason across that material, retrieve the right evidence, preserve attention over long tasks, and avoid turning additional tokens into additional cost without additional value.
DeepSeek, Mistral, Qwen, Z AI, Kimi, Xiaomi, and MBZUAI are not competing only on a downloadable checkpoint. They are pairing models with inference stacks, coding agents, tool protocols, deployment options, and increasingly strong economics. The open-versus-closed debate is evolving into a contest between integrated model, inference, and agent stacks.
Anthropic’s Fable 5 suspension under a US export-control directive—and its use of classifiers and fallback routing for affected requests—showed how regulatory controls can alter a frontier rollout after launch. Google has used preview periods extensively. DeepSeek is consolidating legacy aliases. Enterprises should expect more staged rollouts, regional availability, changing system behavior, and model snapshots that coexist for longer than marketing announcements imply.
Forecast window: August–November 2026
Confidence: Medium
OpenAI released GPT-5.6 on July 9, only months after GPT-5.4 and GPT-5.5. The family is organized into durable capability tiers—Sol, Terra, and Luna—that can improve independently. That structure makes a near-term tier refinement, lower-cost variant, or latency-focused update more likely than an immediate GPT-6 reveal.
My base case is an efficiency-oriented update in late summer, followed by a stronger GPT-5.x frontier release in the autumn. Expect deeper multi-agent orchestration, better coding and computer use, stronger science and cybersecurity performance, and fewer tokens required to reach the same result. OpenAI’s larger strategic move is likely to connect these models more tightly to OpenAI Frontier, its enterprise platform for building, deploying, and governing AI agents.
The biggest uncertainty is naming. The capability may arrive before the generational label.
Forecast window: Grok 4.x refinement in September–November 2026; Grok 5 in late 2026 or early 2027
Confidence: Medium-low
Grok 4.5 arrived on July 8, making another immediate flagship unlikely. A faster, cheaper, or more tool-integrated 4.x release is the more probable next step.
The longer-range signal is stronger: SpaceXAI has said Grok 5 is in training, while SpaceX materials describe Colossus II and a push toward larger-scale pretraining, stronger reasoning fidelity, multimodality, and domain performance. That supports a late-2026-to-early-2027 window, but frontier training schedules are notoriously elastic.
When Grok 5 arrives, expect the story to be about a tightly integrated real-time agent stack spanning software, search, multimodal input, and SpaceXAI’s distribution channels.
Forecast window: September–December 2026
Confidence: Medium-high
Meta’s July release of Muse Spark 1.1 establishes the product direction: a Model API in public preview, multimodal reasoning, coding, computer use, multi-agent operation, and a one-million-token context window. Meta has also said that more capable models are training.
Axios has reported that a substantially larger model, code-named Watermelon, is expected later in 2026. The name and final packaging may change, but a larger autumn flagship is a reasonable forecast.
Look for more autonomous coding and computer-use behavior, deeper multimodal reasoning, and stronger personalization across Meta’s products. The strategic question will be whether Meta treats the larger system as an open-weight release, a hosted API product, or a tiered combination of both.
Forecast window: Late July–August 2026
Confidence: High on the model; medium on timing
Google introduced Gemini 3.5 Flash in May and indicated that Gemini 3.5 Pro would follow. The public Gemini model page still lists the Pro tier as forthcoming, making it the most straightforward prediction in this article.
The timing has already slipped beyond the earliest expectation, so the prudent window is late July through August. The likely emphasis is stronger reasoning, agentic coding, native multimodality, one-million-token-class context, and more dependable tool and computer use. Google’s advantage is not just the model: it can connect Gemini to Workspace, Cloud, Search, Android, and a growing set of agent-development tools.
For enterprises, 3.5 Pro could matter as the model that makes Google’s full-stack agent platform coherent.
Forecast window: September–November 2026, with a cheaper derivative possible earlier
Confidence: Medium-high
Anthropic launched Claude Fable 5 on June 9, followed with Claude Sonnet 5 on June 30, and restored Fable 5 globally on July 1. The company has said that more capable models are coming in the months ahead.
That language, combined with Anthropic’s recent cadence, points to another substantial Claude release in the autumn. A Haiku 5 tier or a Sonnet 5 point update could arrive first.
Expect the next step to focus on long-running coding, research and scientific workflows, vision, memory, and token efficiency. Anthropic is also likely to make production safeguards more explicit, including routing, monitoring, and release controls. The lesson from Fable 5 is that behavioral reliability in deployment can matter as much as a pre-release score.
Forecast window: August–September 2026
Confidence: High
Mistral Medium 3.5 is a dense 128-billion-parameter model with a 256,000-token context window and a unified focus on reasoning, coding, multimodality, and long-running agents. Mistral CEO Arthur Mensch has also signaled a new sparse open-weight family, with partner access in July and a public release later in the summer.
That makes an August or September release one of the stronger forecasts here. A mixture-of-experts design would fit Mistral’s position: high capability with self-hosting economics that appeal to governments and regulated enterprises. Expect multimodal and agentic features, favorable serving economics, and a strong sovereign-AI message; hardware requirements are not yet public.
Mistral may not win the absolute benchmark crown, but it can win important buying decisions where control, locality, and cost matter more than the last few points of intelligence.
Forecast window: Late July–September 2026
Confidence: Medium-high
DeepSeek’s April V4 preview introduced Pro and Flash variants, open weights, a one-million-token context window, dual thinking modes, and sparse designs with 49 billion active parameters for Pro and 13 billion for Flash. DeepSeek is also retiring legacy API aliases on July 24.
Those signals point to consolidation: a stabilized V4, a V4.1-style release, or updated production snapshots. It would be premature to predict V5 simply because competitors are moving quickly.
The likely gains are reliability in tools and coding, smoother production migration, and lower serving cost. DeepSeek’s competitive pressure comes from making frontier-adjacent reasoning inexpensive enough to reshape the economics of every other provider.
Forecast window: Late July–mid-August 2026
Confidence: High for Pro 4; medium for Solar Open 2
Solar Pro 3 uses a mixture-of-experts architecture with 102 billion total parameters and 12 billion active parameters, with a focus on agents, reasoning, and Korean-language performance. In a reported roadmap statement, Upstage leadership targeted Solar Open 2 for the end of June and Solar Pro 4 for the end of July.
The public Open 2 release appears to have slipped, but the combined signal still points to a clustered release window from late July into mid-August.
Expect enterprise tool use, agent reliability, coding, Korean and English performance, and production economics to lead the announcement. Upstage’s opportunity is not to imitate the largest American labs; it is to become the trusted high-performance platform for regional and regulated enterprise use.
Forecast window: August–September 2026
Confidence: Medium
MiniMax M3 arrived on June 1 with native multimodality, one-million-token context, computer use, and a sparse-attention architecture designed for long agent tasks. It followed M2 in October 2025, M2.1 in December, M2.5 in February, and M2.7 in March. That cadence supports another refinement, but M3 is too recent to make a full M4 launch the base case.
A more plausible next step is M3.x: a high-speed tier, a lower-cost serving profile, or a specialized agent and computer-use update. The benchmark chart shows MiniMax already operating in the same broad band as DeepSeek, Kimi, Xiaomi, and Alibaba. A refinement that improves throughput and tool reliability could be more commercially meaningful than a new name.
I would place a major M4 generation in early 2027 unless MiniMax accelerates its historical cadence.
Forecast window: August–October 2026
Confidence: Medium on the flagship name; high on continued releases
Qwen is the hardest portfolio to forecast by name because it ships so often. In the recent benchmark history, Alibaba has far more distinct release dates than any other provider in this group. The Qwen model changelog also shows a portfolio expanding across general intelligence, coding, vision, audio, and agents.
The next general flagship could be branded Qwen 3.8, Qwen 4, or something else entirely. The safer prediction is a late Q3 release that pushes native multimodality, GUI and mobile action, long-horizon coding, persistent memory, and mixture-of-experts efficiency. Qwen’s AgentWorld work provides a useful clue: the laboratory is investing in environments where models learn to operate, not merely answer.
Qwen’s advantage is velocity. It can turn research improvements into a family of deployable models faster than most organizations can finish an evaluation cycle.
Forecast window: August–October 2026; K3 preview plausible in Q4
Confidence: Medium-low
Moonshot AI’s Kimi portfolio has moved from long context toward coding, multimodal reasoning, and interleaved tool use. Its June code-specialist release builds on K2.6 with a 256,000-token context window and a large sparse architecture.
The next likely move is a general-purpose K2.x successor in late summer or early autumn rather than an immediate finished K3. A K3 preview becomes plausible in the fourth quarter, supported by the team’s discussion of a new architecture and more efficient attention mechanisms in a founders’ AMA.
Expect lower reasoning-token cost, tighter think-and-tool loops, stronger multimodality, and longer dependable tasks. Kimi’s strategic differentiator is likely to be efficient agency rather than raw model size.
Forecast window: V2.5 refinement in Q3 2026; major V3-class release in Q4 2026–Q1 2027
Confidence: Medium
MiMo-V2.5-Pro combines a 1.02-trillion-parameter sparse architecture with 42 billion active parameters, a one-million-token context window, and an emphasis on coding and agents. Xiaomi followed with an UltraSpeed serving profile exceeding 1,000 tokens per second and a dedicated coding environment.
That productization work suggests the next release will improve availability, price, speed, memory, and agent harnesses before Xiaomi resets the model number. A more substantial V3-class system is more plausible late in 2026 or early in 2027.
Xiaomi has a distribution advantage most model labs do not: phones, vehicles, home devices, and robotics. The long-term release to watch is the one that turns MiMo from a cloud model into an action layer across that hardware ecosystem.
Forecast window: September–December 2026
Confidence: Medium-low
K2 Think V2 extends MBZUAI’s open K2 foundation with an emphasis on sovereign reasoning. Public roadmap language points toward additional 2026 updates, architectural experimentation, and reinforcement learning for tool and agent behavior.
The sparse release history makes a precise month difficult to defend, but a Q3–Q4 K2 update, K2 V3, or refreshed base model is plausible. Expect the message to center on full-stack sovereignty, transparent weights and data practices, planning, lower hallucination rates, and better tool use.
MBZUAI does not need to match the fastest commercial cadence. Its distinctive role is to prove that frontier-relevant research and deployment infrastructure can be built outside the dominant US and Chinese ecosystems.
Forecast window: August–September 2026; a GLM 6-class move is plausible in Q4
Confidence: Medium-high for 5.x; low for the GLM 6 name
GLM-5.2 arrived in June with a one-million-token context window, long-horizon coding, agentic reinforcement learning, and an efficiency story. It followed GLM 4.6, 4.7, 5, and 5.1 at a rapid pace.
That pattern supports another 5.x point release by September. A GLM 6-class change by the end of the year is plausible, but the label is speculative.
The likely improvements are coding endurance, multi-tool coordination, context stability, agent training, and decoding efficiency. Z AI’s position in the frontier chart is easy to underestimate: its current provider-best score places it just behind the leading US labs and among the strongest challengers.
If the signals hold, the next wave should unfold in four overlapping phases:
Late July through August 2026
August through September 2026
September through November 2026
Fourth quarter 2026 through first quarter 2027
The ordering matters more than the exact week. The market is moving toward continuous deployment, where every quarter contains several releases capable of changing an enterprise model portfolio.
No single provider leads every combination of reasoning, coding, multimodality, latency, cost, data residency, and deployment control. Architect an abstraction layer that can route workloads across at least two frontier providers and one credible open-weight option.
Traditional question-and-answer benchmarks are necessary but insufficient. Measure task completion, tool-call accuracy, recovery after failure, policy compliance, elapsed time, and total cost. A model that scores slightly lower but finishes reliably can be the better production system.
Point releases can alter tone, safety behavior, tool selection, token consumption, and failure modes. Pin versions where possible. Maintain regression suites. Require a controlled promotion process even when a provider describes an update as an improvement.
The capital-expenditure boom does not guarantee that the exact model, region, throughput, or price tier you need will always be available. Capacity commitments, fallback models, data-export rights, and portable agent tooling belong in procurement discussions now.
An agent that can browse, write code, send messages, change records, or operate software creates a different risk profile from a chatbot. Governance must cover identity, delegated authority, tool permissions, audit trails, human approval points, memory, and rollback—not just model content.
The next era of AI will arrive through a dense sequence of frontier upgrades, open-weight model families, faster serving tiers, and increasingly capable agents.
The benchmarks say the competitive field is widening. The capital-expenditure chart says the industry has funded the infrastructure to keep it moving. The product announcements say that the target has shifted from better conversation to dependable digital labor.
For enterprise leaders, the winning prediction is not which lab tops the next chart. It is that model capability, price, and deployment options will change faster than most governance and procurement cycles. That means investing in a model garden instead of a single model or provider. The organizations that win here will be the ones that can evaluate quickly, switch safely, govern autonomous systems, and convert a relentless release cycle into measurable work.
Disclosure: All future release windows in this article are analytical estimates based on public information available as of July 11, 2026. They are not vendor announcements. Corporate capital expenditure includes more than AI infrastructure and should be interpreted as a directional investment signal rather than AI-only spending.
", "url": "https://tedt.org/The-Next-AI-Model-Wave-Has-Already-Been-Funded/", "image": "/img/2026-07/Next-AI-Model-Wave.webp", "tags": ["ai models","frontier models","enterprise ai","ai agents","model garden","open weights","ai governance","model evaluation","hyperscaler capex","autonomous systems"], "date_published": "2026-07-11T09:00:00-07:00", "date_modified": "2026-07-11T09:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/Beyond-the-Light-Bulb/", "title": "Beyond the Light Bulb: The Executive Work of AI Adoption", "summary": "Enterprise AI will not create durable value through license rollouts alone. The real work is redesigning value streams, evidence, governance, roles, and decision loops so AI can safely take on more responsibility.", "content_text": "Beyond the Light Bulb: The Executive Work of AI AdoptionMost large enterprises are asking: Where is the ROI?It is the question boards ask. It is the question CFOs ask. It is the question every executive sponsor feels when the demo is impressive, the license count is rising, and the financial impact still looks a little foggy.But it may not be the first question leaders should ask.A better question is this: What kind of organization do we need to become for AI to matter?That question changes the conversation.It moves AI out of the category of “tool rollout” and into the deeper work of leadership: operating model, accountability, governance, talent, decision rights, and trust.Because AI is not behaving like ordinary software.If AI were simply another productivity tool, the playbook would be familiar. Buy the licenses. Train the users. Measure the hours saved. Report the benefit.But if AI is a general-purpose technology, more like electricity, computing, or the internet, the payoff curve looks different. The first gains are real, but they are often scattered. The larger gains appear only when companies redesign how work flows, how decisions are made, and how people and machines share responsibility.That is why many enterprises feel as if they are standing under the marine layer before the sun breaks through. There is light above them. They can feel the warmth coming. But the horizon still looks gray.They have launched pilots. They have purchased Copilot licenses. Employees are drafting emails, summarizing meetings, producing first-pass analysis, writing code, and generating reports.And yet the bottom line has not moved very much.That does not mean AI has failed.It likely means the enterprise is still in the early season of absorbing a technology that requires more than adoption. It requires reimagination.The history of electricity gives us a useful warning. Early manufacturers used electricity to illuminate factories. They added light bulbs so people could work longer. But the real productivity breakthrough did not come from adding more bulbs. It came when the factory itself was redesigned around flow, standardization, supplier relationships, buyer dynamics, and a new production model. AI is similar. The enterprise does not reach the next horizon by issuing more licenses to more people. The source transcript calls today’s moment the “light bulb stage”: useful, visible, and early.The executive lesson is simple, and humbling:AI adoption is not a technology rollout. It is an operating-model transition.The Light Bulb Stage of AIMost enterprises are still using AI to make existing work faster.That is not a bad thing.Light bulbs are useful. They help people see. They extend the day. They make work easier.But they do not redesign the factory.Today, AI drafts text. It summarizes calls. It helps analysts prepare reports. It helps developers write code. It helps service teams respond to customers. It helps legal teams compare clauses. It helps finance teams explain variances.These are good uses. They build confidence. They reduce friction. They help people learn what AI can and cannot do.But faster local work does not automatically create enterprise value.A finance team may produce analysis faster, but the close process still depends on controls, reconciliations, approvals, and audit evidence.A legal team may draft faster, but contracting still depends on risk appetite, fallback positions, commitment authority, and escalation rules.A development team may generate more code, but architecture review, testing, security, release management, and production support may become the new bottleneck.A service team may draft customer responses faster, but policy interpretation, exception handling, and customer remediation may still slow the work down.This is the 405 at rush hour problem. One lane moving faster does not help much if the whole freeway is jammed. Sometimes it just gets you to the next brake light sooner.Once one part of the company becomes more productive with AI, it may produce more output than the next part of the process can absorb. One group accelerates, but the whole value stream does not.That is the first executive trap:Mistaking local acceleration for enterprise transformation.The second trap is believing the payoff will arrive automatically when the technology gets better.Better models will help. Lower costs will help. Stronger reasoning, longer context windows, and more reliable agents will help.But the central barrier is not only technical reliability.The harder challenge is organizational absorption.Even if the technology became dramatically more reliable, the move from chatbots to workflows to autonomous decision loops would still be difficult, because the deeper challenge is reconceiving how the firm works. The transcript states this plainly: companies are struggling less with pure reliability and more with absorbing the technology into the business as it exists today.That is not a procurement problem.That is leadership work.AI Maturity Is a Ladder of TrustA practical way to think about AI adoption is through maturity.But maturity is often misunderstood.A company is not AI-mature because it has the newest model, the biggest license count, or the most exciting internal demo.A company becomes AI-mature when it can safely give AI more responsibility inside real work.The AI maturity guide makes this distinction well: the five levels are “not a ladder of tool sophistication.” They are “a ladder of organizational operating trust.” At each step, AI takes on more implementation responsibility, and humans move toward the grey areas of specification, evaluation, and judgment.That is the shift executives need to see.At low maturity, humans produce and AI assists.At middle maturity, AI produces and humans review.At higher maturity, humans specify, govern, evaluate, and improve the system that produces the work.This pattern began with software, but it applies across the enterprise. In every repeatable value stream, AI maturity moves through the same progression: AI helps humans work faster, then completes bounded tasks, then handles multi-step work, then produces larger work products for approval, then executes from specifications, and eventually operates an end-to-end workflow under governed controls.For executives, the maturity question is not: How much AI are we using?The question is: How much of this value stream can we safely specify, evaluate, govern, and improve?That is a very different question.It forces leaders to ask what work AI is allowed to perform, what evidence proves the work is correct, who owns the outcome, what happens when AI is wrong, which decisions still require human judgment, and what controls must exist before autonomy increases.This is where the conversation becomes serious.And hopeful.Because AI maturity is not about replacing human contribution. It is about moving human contribution to the highest-value part of the work.The Bottleneck Does Not Disappear. It Moves.Every level of AI maturity removes one bottleneck and reveals another.At first, AI reduces typing, drafting, summarizing, searching, and first-pass production.Then it reduces task execution.Then it reduces multi-step assembly.Then it reduces direct human production.Eventually, in bounded domains, it may reduce human participation in the normal path of routine work.But the bottleneck does not disappear.It moves.The maturity guide says that at higher levels, the scarce resource is no longer generation. It is the ability to describe the right thing, create trustworthy evaluation, contain integration risk, and decide whether the result serves real users.That pattern shows up across the enterprise.In finance, the bottleneck moves from preparing analysis to trusting the evidence behind the analysis.In legal, it moves from drafting language to governing commitment authority.In procurement, it moves from collecting supplier information to making defensible tradeoffs.In HR, it moves from producing talent artifacts to proving fair and lawful judgment.In customer operations, it moves from responding quickly to resolving correctly and fairly.In audit and compliance, it moves from documenting controls to proving that controls actually work.This is where AI programs often stall.They automate artifact creation but do not improve decision quality.They generate more work but do not redesign approval flow.They increase output but do not strengthen validation.They reduce manual effort but do not clarify accountability.They accelerate teams but do not improve the enterprise loop.The most important enterprise translation is this: the bottleneck moves from task production to decision quality. AI can draft the memo, prepare the packet, summarize the case, recommend the next action, and route the work. But the enterprise still has to know what decision is being made, who is accountable, what evidence is sufficient, which constraints are non-negotiable, what exceptions require judgment, and what harm occurs if the answer is wrong.That is why AI adoption belongs on the executive agenda.Not as innovation theater. Not as a side experiment. Not as a license activation dashboard.But as a question of how the organization will make better decisions, faster, with stronger evidence and clearer accountability.The Next Advantage Is Not Workflow. It Is Loop Speed.The next stage of AI adoption will not be defined by isolated copilots.It will be defined by tighter decision loops.There is a progression from chatbots, to workflows, to loops. The loop world is about changing how the company senses, decides, acts, learns, and adapts. It is not merely about reducing cost. It is about reducing delay.That matters because first-wave productivity gains may not last.If one company uses AI to make its sales force more productive, competitors can do the same. And once that happens customers will expect it.If one legal team drafts faster, others can follow.If one finance organization produces better summaries, that advantage may disappear quickly.Stage-one and stage-two gains can be competed away. A company may lower costs for a season, but competitors will follow, and the remaining difference may simply be a larger AI bill.The more durable advantage comes when AI changes the organization’s learning rate.The question shifts from: How do we help every employee go faster?to: How do we help the enterprise learn and adapt faster?A company with AI-assisted people may become more productive.A company with AI-assisted workflows may become more efficient.But a company with AI-enabled decision loops may become more adaptive.That is the real promise of AI.Not fewer tasks. Not faster drafts. Not a little more speed in every inbox.The promise is a healthier organizational metabolism.A company that senses sooner. Learns faster. Responds more wisely. Corrects itself more honestly. And focuses human judgment where it matters most.The Executive PlaybookThe practical path forward is not to chase full autonomy everywhere.That is how companies create confusion, risk, and disappointment.The best path is to raise maturity deliberately, value stream by value stream.Like building a campfire, the order matters. You do not start with the biggest log and hope the flame figures it out. You prepare the ground. You gather kindling. You protect the spark. You feed the fire in stages.AI adoption works the same way. Leadership must build the conditions that allow it to become useful heat.1. Stop Measuring Adoption by LicensesLicense activation is not transformation. Prompt volume is not transformation. Pilot count is not transformation.Executives should measure AI adoption by value-stream outcomes:cycle time, quality, cost, risk, customer impact, employee experience, decision latency, exception rate, rework, control effectiveness, and throughput across the full process.A team may produce 40% more work with AI and still create little enterprise value if downstream review, approval, compliance, integration, or customer consumption cannot absorb the increase.The question is not: How many people are using AI?The question is: Which business outcomes are improving because AI changed how work actually moves?2. Map AI Maturity by Value StreamDo not declare, “We are at Level 3,” or “We are AI-native.”Different teams and processes will operate at different maturity levels. Leaders should not average maturity across the enterprise. Record separate maturity levels by team, workflow, product area, or value stream.Finance close support may be Level 1. Software maintenance may be Level 2. Customer response drafting may be Level 3. Contract intake may be ready for Level 4.Some compliance workflows may need to remain at Level 1 because the cost of false assurance is too high.This creates an honest mapthat keep leaders from pretending the house is finished when the foundation is still curing.3. Choose the Right Early CandidatesAI works best early where the work is high-volume, repeatable, coordination-heavy, and governed by clear but distributed rules.Good candidates include evidence packet creation, routine case triage, standard contract intake, low-risk purchasing, forecast support, customer response preparation, control testing support, work package assembly, and knowledge-base maintenance.Poor early candidates include high-impact employment decisions, novel legal interpretations, safety-critical field decisions, material financial judgments, regulatory filings without human accountability, irreversible customer-impacting decisions, and processes where the rules are mostly tribal knowledge.This is a sequencing principle.Do not begin with the flashiest use case.Begin where the work is repeatable, valuable, measurable, and recoverable.Begin where the enterprise can specify the work, test the output, govern the risk, and learn without burning trust.The goal is not to impress the room with a dramatic demo.The goal is to build confidence that survives production.4. Build Specifications Before AutonomyAt low maturity, prompting is survivable because humans remain close to the work.At higher maturity, vague prompts and specifications become operational risk.This is one of the most important shifts for executives.The enterprise asset is not only the AI.The enterprise asset is the ability for your employees to document tacit expertise into explicit operating knowledge.Your best people know how the business really works.They know the edge cases. They know the exceptions. They know the hidden rules.They know the customer sensitivities, regulatory tripwires, judgment calls, and failure modes.Much of that wisdom lives in hallway conversations, spreadsheet notes, email threads, senior reviewers’ memories, and the quiet intuition of people who have carried the work for years.AI adoption forces that knowledge into the light.Onto paper.Into specifications.Into scenarios planning.Into audit controls.Into evaluation rubrics.Into standard operating procedure playbooks.That is not bureaucracy. That is stewardship.The is what this looks like. AI software tests are business rules, controls, reconciliations, approvals, validation checks, policy checks, and outcome measures. AI agent scenarios are customer journeys, regulatory examples, exception paths, and failure simulations. This is how AI autonomy becomes safe.Not by trusting the machine more. By making the work clearer. And if you don’t have standard business rules, controls, reconciliations, approvals, validation checks, policy checks, outcome measures, customer journeys, regulatory examples, exception paths, and failure simulations, you cannot safely scale AI autonomy. Thankfully though the one thing you do have is a list of things to do and a team to do them with. That is enough to get started.5. Design Evidence Before Work StartsIn traditional workflows, review often happens after the work is produced.In AI-enabled workflows, quality must move in before the work starts so that evidence is produced while the work is being produced.Before AI generates a contract review, define what evidence proves the review is acceptable.Before AI prepares a forecast package, define reconciliation checks and confidence thresholds.Before AI resolves a customer case, define policy constraints and escalation triggers.Before AI drafts audit workpapers, define evidence lineage and sampling expectations.Before AI changes software, define scenario tests and rollback paths.It is not whether AI can draft the document or recommend the action. It usually can. The hard part is whether the enterprise can prove the work was correct, authorized, explainable, compliant, trustable, and reversible when something goes wrong.That sentence belongs on every AI steering committee agenda.Because polished output is not the same thing as trustworthy work.A beautiful answer without evidence is like a lunchbox packed with candy and no actual lunch. It looks exciting at 8 a.m. By noon, everybody regrets the decision.Executives must insist on every process having quality built into them by having those proceess produce evidence by design.Not evidence as decoration. Not evidence as a screenshot pasted into a ticket. Evidence as part of the operating system.6. Redesign Roles Around JudgmentAI does not simply eliminate work. It changes what valuable work looks like.At lower levels, people are rewarded for producing the artifact directly: the report, the contract language, the forecast, the work order, the audit workpaper, the customer response, the plan.At higher levels, people are rewarded for shaping the work system: defining intent, writing better specifications, setting constraints, evaluating outcomes, managing exceptions, and improving the value stream.That means role design must change.The finance analyst becomes less of a spreadsheet producer and more of a financial evidence reviewer.The attorney becomes less of a first-draft machine and more of a legal judgment owner.The recruiter becomes less of a resume sorter and more of a fairness-aware evidence curator.The customer service agent becomes less of a script follower and more of an exception handler and trust repairer.The architect becomes less of a standards enforcer and more of an autonomy architect across enterprise value streams.The executive sponsor becomes the owner of risk appetite, autonomy boundaries, outcome metrics, governance, and accountability.Across these roles, the same pattern repeats: the work moves from producing artifacts to specifying outcomes, from informal knowledge to explicit rules, from reviewing finished work to designing evidence before work starts, from manual coordination to exception governance, and from output quality to outcome quality.This is one of the more hopeful implications of AI.Human expertise does not become less important. It becomes more important.The people who thrive will be those who can turn experience into specifications, scenarios, controls, decision criteria, and better operating models.What Leaders Should Do in the Next 90 DaysFor executives, the next move should be concrete.Pick three to five high-value enterprise workflows.For each one, document: The current maturity level. The target maturity level. The accountable business owner. The work product, decision, transaction, or customer outcome. The systems of record. The data sensitivity. The governing policies and controls. The acceptance criteria. The exception paths. The audit evidence. The rollback or correction path when things go wrong. The operating metrics, including quality, risk, cost, cycle time, and user impact.Then ask the harder questions: Where are we using AI only to create more artifacts? Where has AI moved the bottleneck downstream? Where are reviewers overloaded? Where are we accepting polished work without sufficient evidence? Where do we lack specifications strong enough for higher autonomy? Where are human approvals real, and where are they theater? Where would a failure harm customers, employees, financial integrity, safety, compliance, or trust? Where could we safely move one level higher?The goal is not to leap to full autonomy.The goal is to build confidence through governed progression.A Level 1 workflow that is well controlled is better than a Level 4 workflow built on vague rules and heroic review.A Level 2 process with clear boundaries, strong evidence, and accountable owners is more valuable than a flashy agent demo that cannot survive audit, exception handling, or production pressure.The correct maturity target is not the highest level the tool can demonstrate.It is the highest level the operating model can govern.The Leadership ShiftAI adoption will reward leaders who can hold two truths at the same time.First, the opportunity is enormous: Large enterprises are full of repeatable work, fragmented knowledge, slow handoffs, manual coordination, decision latency, and underused data. AI can compress cycle times, improve decision support, reduce toil, increase responsiveness, and make expertise more reusable.Second, the work is harder than buying software.The companies that win will not be the ones that deploy tools fastest.They will be the ones that redesign how intent becomes action, how evidence supports decisions, how exceptions find humans, how controls operate inside workflows, and how the organization learns.The first era of enterprise AI was experimentation.The second era is workflow productivity.The third era will be governed autonomy.That third era is where the real prize lies.Not an enterprise where humans disappear.But an enterprise where human judgment is focused where it matters most.AI can produce more work. Leadership must decide what work is worth producing.AI can accelerate workflows. Leadership must decide which loops should move faster.AI can generate recommendations. Leadership must define the evidence required to trust them.AI can automate routine decisions. Leadership must protect the exceptions where values, judgment, and accountability matter.The organizations that thrive will be those that become clearer, not just faster.Clearer about intent.Clearer about evidence.Clearer about risk.Clearer about decision rights.Clearer about accountability.Clearer about what only humans should own.That is the real promise of AI adoption in large enterprises.Not simply that machines will do more of the work.But that leaders have an opportunity to redesign the enterprise around better work, faster learning, and more disciplined judgment.The future belongs to organizations that can turn AI from a tool into an operating model.And the path begins not with another license rollout, but with a leadership decision:We will not merely add light bulbs.We will build the factory.", "content_html": "Most large enterprises are asking: Where is the ROI?
It is the question boards ask. It is the question CFOs ask. It is the question every executive sponsor feels when the demo is impressive, the license count is rising, and the financial impact still looks a little foggy.
But it may not be the first question leaders should ask.
A better question is this: What kind of organization do we need to become for AI to matter?
That question changes the conversation.
It moves AI out of the category of “tool rollout” and into the deeper work of leadership: operating model, accountability, governance, talent, decision rights, and trust.
Because AI is not behaving like ordinary software.
If AI were simply another productivity tool, the playbook would be familiar. Buy the licenses. Train the users. Measure the hours saved. Report the benefit.
But if AI is a general-purpose technology, more like electricity, computing, or the internet, the payoff curve looks different. The first gains are real, but they are often scattered. The larger gains appear only when companies redesign how work flows, how decisions are made, and how people and machines share responsibility.
That is why many enterprises feel as if they are standing under the marine layer before the sun breaks through. There is light above them. They can feel the warmth coming. But the horizon still looks gray.
They have launched pilots. They have purchased Copilot licenses. Employees are drafting emails, summarizing meetings, producing first-pass analysis, writing code, and generating reports.
And yet the bottom line has not moved very much.
That does not mean AI has failed.
It likely means the enterprise is still in the early season of absorbing a technology that requires more than adoption. It requires reimagination.
The history of electricity gives us a useful warning. Early manufacturers used electricity to illuminate factories. They added light bulbs so people could work longer. But the real productivity breakthrough did not come from adding more bulbs. It came when the factory itself was redesigned around flow, standardization, supplier relationships, buyer dynamics, and a new production model. AI is similar. The enterprise does not reach the next horizon by issuing more licenses to more people. The source transcript calls today’s moment the “light bulb stage”: useful, visible, and early.
The executive lesson is simple, and humbling:
AI adoption is not a technology rollout. It is an operating-model transition.
Most enterprises are still using AI to make existing work faster.
That is not a bad thing.
Light bulbs are useful. They help people see. They extend the day. They make work easier.
But they do not redesign the factory.
Today, AI drafts text. It summarizes calls. It helps analysts prepare reports. It helps developers write code. It helps service teams respond to customers. It helps legal teams compare clauses. It helps finance teams explain variances.
These are good uses. They build confidence. They reduce friction. They help people learn what AI can and cannot do.
But faster local work does not automatically create enterprise value.
A finance team may produce analysis faster, but the close process still depends on controls, reconciliations, approvals, and audit evidence.
A legal team may draft faster, but contracting still depends on risk appetite, fallback positions, commitment authority, and escalation rules.
A development team may generate more code, but architecture review, testing, security, release management, and production support may become the new bottleneck.
A service team may draft customer responses faster, but policy interpretation, exception handling, and customer remediation may still slow the work down.
This is the 405 at rush hour problem. One lane moving faster does not help much if the whole freeway is jammed. Sometimes it just gets you to the next brake light sooner.
Once one part of the company becomes more productive with AI, it may produce more output than the next part of the process can absorb. One group accelerates, but the whole value stream does not.
That is the first executive trap:
Mistaking local acceleration for enterprise transformation.
The second trap is believing the payoff will arrive automatically when the technology gets better.
Better models will help. Lower costs will help. Stronger reasoning, longer context windows, and more reliable agents will help.
But the central barrier is not only technical reliability.
The harder challenge is organizational absorption.
Even if the technology became dramatically more reliable, the move from chatbots to workflows to autonomous decision loops would still be difficult, because the deeper challenge is reconceiving how the firm works. The transcript states this plainly: companies are struggling less with pure reliability and more with absorbing the technology into the business as it exists today.
That is not a procurement problem.
That is leadership work.
A practical way to think about AI adoption is through maturity.
But maturity is often misunderstood.
A company is not AI-mature because it has the newest model, the biggest license count, or the most exciting internal demo.
A company becomes AI-mature when it can safely give AI more responsibility inside real work.
The AI maturity guide makes this distinction well: the five levels are “not a ladder of tool sophistication.” They are “a ladder of organizational operating trust.” At each step, AI takes on more implementation responsibility, and humans move toward the grey areas of specification, evaluation, and judgment.
That is the shift executives need to see.
At low maturity, humans produce and AI assists.
At middle maturity, AI produces and humans review.
At higher maturity, humans specify, govern, evaluate, and improve the system that produces the work.
This pattern began with software, but it applies across the enterprise. In every repeatable value stream, AI maturity moves through the same progression: AI helps humans work faster, then completes bounded tasks, then handles multi-step work, then produces larger work products for approval, then executes from specifications, and eventually operates an end-to-end workflow under governed controls.
For executives, the maturity question is not: How much AI are we using?
The question is: How much of this value stream can we safely specify, evaluate, govern, and improve?
That is a very different question.
It forces leaders to ask what work AI is allowed to perform, what evidence proves the work is correct, who owns the outcome, what happens when AI is wrong, which decisions still require human judgment, and what controls must exist before autonomy increases.
This is where the conversation becomes serious.
And hopeful.
Because AI maturity is not about replacing human contribution. It is about moving human contribution to the highest-value part of the work.
Every level of AI maturity removes one bottleneck and reveals another.
At first, AI reduces typing, drafting, summarizing, searching, and first-pass production.
Then it reduces task execution.
Then it reduces multi-step assembly.
Then it reduces direct human production.
Eventually, in bounded domains, it may reduce human participation in the normal path of routine work.
But the bottleneck does not disappear.
It moves.
The maturity guide says that at higher levels, the scarce resource is no longer generation. It is the ability to describe the right thing, create trustworthy evaluation, contain integration risk, and decide whether the result serves real users.
That pattern shows up across the enterprise.
In finance, the bottleneck moves from preparing analysis to trusting the evidence behind the analysis.
In legal, it moves from drafting language to governing commitment authority.
In procurement, it moves from collecting supplier information to making defensible tradeoffs.
In HR, it moves from producing talent artifacts to proving fair and lawful judgment.
In customer operations, it moves from responding quickly to resolving correctly and fairly.
In audit and compliance, it moves from documenting controls to proving that controls actually work.
This is where AI programs often stall.
They automate artifact creation but do not improve decision quality.
They generate more work but do not redesign approval flow.
They increase output but do not strengthen validation.
They reduce manual effort but do not clarify accountability.
They accelerate teams but do not improve the enterprise loop.
The most important enterprise translation is this: the bottleneck moves from task production to decision quality. AI can draft the memo, prepare the packet, summarize the case, recommend the next action, and route the work. But the enterprise still has to know what decision is being made, who is accountable, what evidence is sufficient, which constraints are non-negotiable, what exceptions require judgment, and what harm occurs if the answer is wrong.
That is why AI adoption belongs on the executive agenda.
Not as innovation theater. Not as a side experiment. Not as a license activation dashboard.
But as a question of how the organization will make better decisions, faster, with stronger evidence and clearer accountability.
The next stage of AI adoption will not be defined by isolated copilots.
It will be defined by tighter decision loops.
There is a progression from chatbots, to workflows, to loops. The loop world is about changing how the company senses, decides, acts, learns, and adapts. It is not merely about reducing cost. It is about reducing delay.
That matters because first-wave productivity gains may not last.
If one company uses AI to make its sales force more productive, competitors can do the same. And once that happens customers will expect it.
If one legal team drafts faster, others can follow.
If one finance organization produces better summaries, that advantage may disappear quickly.
Stage-one and stage-two gains can be competed away. A company may lower costs for a season, but competitors will follow, and the remaining difference may simply be a larger AI bill.
The more durable advantage comes when AI changes the organization’s learning rate.
The question shifts from: How do we help every employee go faster?
to: How do we help the enterprise learn and adapt faster?
A company with AI-assisted people may become more productive.
A company with AI-assisted workflows may become more efficient.
But a company with AI-enabled decision loops may become more adaptive.
That is the real promise of AI.
Not fewer tasks. Not faster drafts. Not a little more speed in every inbox.
The promise is a healthier organizational metabolism.
A company that senses sooner. Learns faster. Responds more wisely. Corrects itself more honestly. And focuses human judgment where it matters most.
The practical path forward is not to chase full autonomy everywhere.
That is how companies create confusion, risk, and disappointment.
The best path is to raise maturity deliberately, value stream by value stream.
Like building a campfire, the order matters. You do not start with the biggest log and hope the flame figures it out. You prepare the ground. You gather kindling. You protect the spark. You feed the fire in stages.
AI adoption works the same way. Leadership must build the conditions that allow it to become useful heat.
License activation is not transformation. Prompt volume is not transformation. Pilot count is not transformation.
Executives should measure AI adoption by value-stream outcomes:
cycle time, quality, cost, risk, customer impact, employee experience, decision latency, exception rate, rework, control effectiveness, and throughput across the full process.
A team may produce 40% more work with AI and still create little enterprise value if downstream review, approval, compliance, integration, or customer consumption cannot absorb the increase.
The question is not: How many people are using AI?
The question is: Which business outcomes are improving because AI changed how work actually moves?
Do not declare, “We are at Level 3,” or “We are AI-native.”
Different teams and processes will operate at different maturity levels. Leaders should not average maturity across the enterprise. Record separate maturity levels by team, workflow, product area, or value stream.
Finance close support may be Level 1. Software maintenance may be Level 2. Customer response drafting may be Level 3. Contract intake may be ready for Level 4.
Some compliance workflows may need to remain at Level 1 because the cost of false assurance is too high.
This creates an honest mapthat keep leaders from pretending the house is finished when the foundation is still curing.
AI works best early where the work is high-volume, repeatable, coordination-heavy, and governed by clear but distributed rules.
Good candidates include evidence packet creation, routine case triage, standard contract intake, low-risk purchasing, forecast support, customer response preparation, control testing support, work package assembly, and knowledge-base maintenance.
Poor early candidates include high-impact employment decisions, novel legal interpretations, safety-critical field decisions, material financial judgments, regulatory filings without human accountability, irreversible customer-impacting decisions, and processes where the rules are mostly tribal knowledge.
This is a sequencing principle.
Do not begin with the flashiest use case.
Begin where the work is repeatable, valuable, measurable, and recoverable.
Begin where the enterprise can specify the work, test the output, govern the risk, and learn without burning trust.
The goal is not to impress the room with a dramatic demo.
The goal is to build confidence that survives production.
At low maturity, prompting is survivable because humans remain close to the work.
At higher maturity, vague prompts and specifications become operational risk.
This is one of the most important shifts for executives.
The enterprise asset is not only the AI.
The enterprise asset is the ability for your employees to document tacit expertise into explicit operating knowledge.
Your best people know how the business really works.
They know the edge cases. They know the exceptions. They know the hidden rules.
They know the customer sensitivities, regulatory tripwires, judgment calls, and failure modes.
Much of that wisdom lives in hallway conversations, spreadsheet notes, email threads, senior reviewers’ memories, and the quiet intuition of people who have carried the work for years.
AI adoption forces that knowledge into the light.
Onto paper.
Into specifications.
Into scenarios planning.
Into audit controls.
Into evaluation rubrics.
Into standard operating procedure playbooks.
That is not bureaucracy. That is stewardship.
The is what this looks like. AI software tests are business rules, controls, reconciliations, approvals, validation checks, policy checks, and outcome measures. AI agent scenarios are customer journeys, regulatory examples, exception paths, and failure simulations. This is how AI autonomy becomes safe.
Not by trusting the machine more. By making the work clearer. And if you don’t have standard business rules, controls, reconciliations, approvals, validation checks, policy checks, outcome measures, customer journeys, regulatory examples, exception paths, and failure simulations, you cannot safely scale AI autonomy. Thankfully though the one thing you do have is a list of things to do and a team to do them with. That is enough to get started.
In traditional workflows, review often happens after the work is produced.
In AI-enabled workflows, quality must move in before the work starts so that evidence is produced while the work is being produced.
Before AI generates a contract review, define what evidence proves the review is acceptable.
Before AI prepares a forecast package, define reconciliation checks and confidence thresholds.
Before AI resolves a customer case, define policy constraints and escalation triggers.
Before AI drafts audit workpapers, define evidence lineage and sampling expectations.
Before AI changes software, define scenario tests and rollback paths.
It is not whether AI can draft the document or recommend the action. It usually can. The hard part is whether the enterprise can prove the work was correct, authorized, explainable, compliant, trustable, and reversible when something goes wrong.
That sentence belongs on every AI steering committee agenda.
Because polished output is not the same thing as trustworthy work.
A beautiful answer without evidence is like a lunchbox packed with candy and no actual lunch. It looks exciting at 8 a.m. By noon, everybody regrets the decision.
Executives must insist on every process having quality built into them by having those proceess produce evidence by design.
Not evidence as decoration. Not evidence as a screenshot pasted into a ticket. Evidence as part of the operating system.
AI does not simply eliminate work. It changes what valuable work looks like.
At lower levels, people are rewarded for producing the artifact directly: the report, the contract language, the forecast, the work order, the audit workpaper, the customer response, the plan.
At higher levels, people are rewarded for shaping the work system: defining intent, writing better specifications, setting constraints, evaluating outcomes, managing exceptions, and improving the value stream.
That means role design must change.
The finance analyst becomes less of a spreadsheet producer and more of a financial evidence reviewer.
The attorney becomes less of a first-draft machine and more of a legal judgment owner.
The recruiter becomes less of a resume sorter and more of a fairness-aware evidence curator.
The customer service agent becomes less of a script follower and more of an exception handler and trust repairer.
The architect becomes less of a standards enforcer and more of an autonomy architect across enterprise value streams.
The executive sponsor becomes the owner of risk appetite, autonomy boundaries, outcome metrics, governance, and accountability.
Across these roles, the same pattern repeats: the work moves from producing artifacts to specifying outcomes, from informal knowledge to explicit rules, from reviewing finished work to designing evidence before work starts, from manual coordination to exception governance, and from output quality to outcome quality.
This is one of the more hopeful implications of AI.
Human expertise does not become less important. It becomes more important.
The people who thrive will be those who can turn experience into specifications, scenarios, controls, decision criteria, and better operating models.
For executives, the next move should be concrete.
Pick three to five high-value enterprise workflows.
For each one, document:
Then ask the harder questions:
The goal is not to leap to full autonomy.
The goal is to build confidence through governed progression.
A Level 1 workflow that is well controlled is better than a Level 4 workflow built on vague rules and heroic review.
A Level 2 process with clear boundaries, strong evidence, and accountable owners is more valuable than a flashy agent demo that cannot survive audit, exception handling, or production pressure.
The correct maturity target is not the highest level the tool can demonstrate.
It is the highest level the operating model can govern.
AI adoption will reward leaders who can hold two truths at the same time.
First, the opportunity is enormous: Large enterprises are full of repeatable work, fragmented knowledge, slow handoffs, manual coordination, decision latency, and underused data. AI can compress cycle times, improve decision support, reduce toil, increase responsiveness, and make expertise more reusable.
Second, the work is harder than buying software.
The companies that win will not be the ones that deploy tools fastest.
They will be the ones that redesign how intent becomes action, how evidence supports decisions, how exceptions find humans, how controls operate inside workflows, and how the organization learns.
The first era of enterprise AI was experimentation.
The second era is workflow productivity.
The third era will be governed autonomy.
That third era is where the real prize lies.
Not an enterprise where humans disappear.
But an enterprise where human judgment is focused where it matters most.
AI can produce more work. Leadership must decide what work is worth producing.
AI can accelerate workflows. Leadership must decide which loops should move faster.
AI can generate recommendations. Leadership must define the evidence required to trust them.
AI can automate routine decisions. Leadership must protect the exceptions where values, judgment, and accountability matter.
The organizations that thrive will be those that become clearer, not just faster.
Clearer about intent.
Clearer about evidence.
Clearer about risk.
Clearer about decision rights.
Clearer about accountability.
Clearer about what only humans should own.
That is the real promise of AI adoption in large enterprises.
Not simply that machines will do more of the work.
But that leaders have an opportunity to redesign the enterprise around better work, faster learning, and more disciplined judgment.
The future belongs to organizations that can turn AI from a tool into an operating model.
And the path begins not with another license rollout, but with a leadership decision:
We will not merely add light bulbs.
We will build the factory.
", "url": "https://tedt.org/Beyond-the-Light-Bulb/", "image": "/img/2026-07/Beyond-the-light-bulb.webp", "tags": ["ai adoption","enterprise ai","operating model","ai maturity","governed autonomy","decision loops","value streams","ai governance","executive leadership","digital transformation"], "date_published": "2026-07-05T07:00:00-07:00", "date_modified": "2026-07-05T07:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/The-Orion-Accord-and-the-Artemis-Working-Group/", "title": "The Orion Accord and the Artemis Working Group", "summary": "A Traveller faction and campaign framework built around the Orion Accord, a criminal constitution of frontier predators, and the Artemis Working Group, an Imperial intelligence task force created to dismantle the ecosystem that lets Orion hunt.", "content_text": "Mythic FrameThe central mythic tension is this:Orion is the great hunter: magnificent, proud, dangerous, impossible to ignore. He crosses land and sea. He loves, boasts, violates boundaries, is blinded, restored, and finally destroyed by forces he underestimates.Artemis is the divine huntress: patient, precise, austere, protective of wild places and vulnerable people. She is both hunter and guardian. She does not merely kill prey; she maintains the boundary between predator and world.So in this setting:The Orion Accord sees itself as the natural aristocracy of the frontier: hunters, predators, smugglers, brokers, pirates, patrons, and killers who know that civilization is just a temporary agreement between people with enough force to matter.The Artemis Working Group sees Orion not merely as a criminal organization, but as a predatory ecosystem. Its goal is not to arrest individual criminals. Its goal is to restore balance by destroying the conditions that allow Orion to hunt.Their conflict should feel mythic, but not cartoonish. Orion should have charm, discipline, beauty, loyalty, and old codes. Artemis should have nobility, patience, cruelty, secrecy, and the terrifying calm of people who believe they are doing necessary work.The Orion AccordCore IdentityThe Orion Accord is a compact among criminals who have become too sophisticated to waste themselves in open gang war.It is not a single syndicate. It is a criminal constitution.Pirate admirals, smuggling combines, corrupt starport officials, noble patrons, information brokers, mercenary companies, illegal biotech houses, black financiers, rogue intelligence veterans, and underworld judges all operate under its protection.The Accord does three things: It prevents destructive conflict between criminal powers. It enforces contracts that cannot be taken to court. It coordinates crimes too large for any one syndicate to manage alone.An independent corsair captain may not know the names of the Star Council. A noble money-launderer may never meet a pirate. A starport customs official may only know one handler. But all of them understand the same rule:If the Accord recognizes the contract, the contract is real.Its informal motto is: “The hunter belongs to no king.”Its darker internal version is: “All worlds are hunting grounds.”Origin of the Orion AccordProject First HuntCenturies ago, Imperial Intelligence created a covert criminal infiltration program called Project First Hunt.The original purpose was practical and defensible: organized crime had spread across several subsectors, moving faster than local law enforcement could respond. Imperial agencies needed a way to penetrate pirate markets, illegal weapons channels, slave routes, smuggling corridors, and noble-backed black finance.So they built a false criminal network.It had ships, shell companies, corrupt port identities, forged trade codes, dead-drop systems, and undercover officers with lifetime aliases. The program was given enough autonomy to look real. It was allowed to conduct controlled crimes. It laundered funds to preserve cover. It recruited real criminals as disposable assets.Then it worked too well.Within a generation, Project First Hunt was moving more money than some subsector governments. It possessed hidden depots, compromised officials, blackmail on nobles, and ships that did not appear on Imperial ledgers. Its officers had spent so long acting like criminals that some of them stopped distinguishing between cover and vocation.The break came during what Artemis files call the Chios Incident.Orion records call it the Blinding.The Chios IncidentA senior Imperial patron, later remembered in Orion myth as Oenopion, attempted to shut down Project First Hunt after discovering that its criminal revenue had been diverted into unauthorized operations. The official purge erased identities, burned safe houses, froze accounts, and assassinated several deep-cover officers.The project survived because its criminals survived.Cut off from official command, its surviving officers and assets formed a mutual-defense compact. They still had ships. They still had secrets. They still had contacts. Most importantly, they had proof of Imperial complicity.That compact became the Orion Accord.The founding members did not see themselves as traitors. In their telling, the Empire had created hunters, used them, blinded them, and left them to die. The survivors simply chose to keep hunting.Artemis takes the opposite view: Orion was not abandoned. Orion defected.Both are partly true.Orion’s Self-MythThe Accord teaches a private version of the Orion myth to trusted initiates.In their version:Orion was the greatest hunter mortal blood ever produced. He could walk over the sea because no frontier could contain him. Kings wanted to command him. Gods wanted to humble him. Lovers wanted to possess him. Lesser men wanted to blind him. Nature itself had to create the scorpion because no ordinary enemy could defeat him.The lesson is not “do not be proud.”The lesson is: “If the gods send a scorpion, you have become worthy of fear.”This is how Orion members justify their existence. The Empire is Hera. Artemis is betrayal. Apollo is manipulation. Gaia is the old order defending itself. The Scorpion is the knife the powerful use when law fails.To the Accord, criminality is not shameful. It is proof that one has outgrown permission.Symbols and RecognitionThe Black Star StoneThe most important Orion symbol is a polished black gemstone or synthetic crystal containing a faint embedded pattern of Orion’s constellation.The cheapest versions are just underworld fashion. The real ones are encrypted identity tokens.A genuine Black Star Stone may contain: A dead-drop coordinate. A one-time decryption key. Membership proof. A hidden account address. A record of debt. A kill authorization. A fragment of the old Project First Hunt command architecture.Most stones show three brighter points representing Orion’s Belt. High-ranking members may also have red and blue-white flecks representing Betelgeuse and Rigel.To outsiders, it is jewelry.To those who know, it says:This person is under the Accord. Harm them casually and the matter becomes political.The Three StarsThe Accord’s most common hand sign is three slow taps: table, chest, table.It means:Debt. Name. Ground.Debt: all things have price.Name: identity is a weapon.Ground: every place belongs to whoever can hold it.The taps are also used in coded comms. Three repeated packet delays in a transmission may signal an Accord relay. Three minor irregularities in a shipping manifest may indicate that cargo is protected.Structure of the Orion AccordThe Accord avoids formal titles that can be mapped by investigators. Its structure is mythic, ritualized, and intentionally ambiguous.QuarryNon-members who are useful to the Accord.A Quarry may be a corrupt official, a desperate merchant, a compromised naval clerk, a gambler in debt, or a noble heir with an addiction. They are not trusted. They are hunted without always knowing it.A Quarry can become a recruit, asset, hostage, or warning.Orion slang: “Every hunter begins by learning what it feels like to be prey.”SpoorInformation sources and low-level assets.Spoor includes informants, hacked databases, bribed dockworkers, minor couriers, gossip brokers, and compromised software systems. Spoor is not considered part of Orion, but Orion treats it as part of the terrain.An Artemis Tracker who discovers a Spoor network has usually found the edge of an Accord operation, not its heart.HuntersFull field operatives.Hunters are smugglers, thieves, killers, pirates, brokers, ship captains, face-men, cyber-intrusion specialists, and criminal troubleshooters. They have recognized standing under the Accord and may invoke its arbitration.A Hunter is expected to be competent, discreet, and profitable.A Hunter who makes noise is reprimanded.A Hunter who makes enemies without profit is fined.A Hunter who brings Imperial heat onto Accord infrastructure may become subject to internal sanction.GuidesRegional coordinators.A Guide knows routes, ports, local officials, criminal personalities, and safe houses across a cluster of worlds. They do not usually command Hunters directly. Instead, they connect people who need each other.A Guide can arrange: False papers. Emergency extraction. Cargo disappearance. Ship transponder replacement. Starport labor unrest. Courtroom pressure. Quiet medical services. A meeting with someone more dangerous.Guides are the Accord’s true middle class. Killing one without authorization is a major offense.BeltmastersThe Accord always has three visible senior authorities, collectively called the Belt.They are not the highest leaders, but they are the highest people most members can petition.Each Beltmaster governs one pillar of criminal power.Alnitak — ViolenceThe Alnitak seat manages mercenary contracts, enforcement, piracy, assassination permissions, hostage rules, and war between members.Alnitak does not order every killing, but decides which killings matter.Alnilam — InformationThe Alnilam seat manages blackmail archives, intelligence markets, identity fabrication, encrypted communications, and secrets recovered from Imperial systems.Alnilam is feared more than Alnitak by people who understand the Accord.Mintaka — WealthThe Mintaka seat manages finance, laundering, trade fraud, shell companies, debt ledgers, bond manipulation, and noble investment channels.Mintaka makes sure everyone gets paid, including people who do not admit they are being paid.The Star CouncilAbove the Belt is the Star Council.No one knows how many members it truly has. Tradition says nine, but that may be symbolic. Some believe each councilor corresponds to a major star in Orion. Others think the “nine” includes dead founders whose votes are simulated by legacy algorithms.Possible truths: The Star Council has nine living members. The Star Council has six living members and three artificial decision systems. The Star Council is a myth used by the Beltmasters to legitimize decisions. One seat is held by an Imperial noble. One seat is held by an Artemis mole. One seat is still occupied by the original Project First Hunt command intelligence. The Council is not above the Accord; it is trapped by it.The Star Council rarely gives orders. It issues interpretations of the Accord.In practice, that is more powerful.The Seven Articles of the AccordThe Accord’s internal law is known as the Seven Articles.Different cells recite them differently, but the core principles remain.I. The Hunt Has BoundariesMembers may compete, deceive, and profit, but they may not destroy the hunting ground itself. No action may cause enough Imperial attention to endanger major Accord infrastructure without prior sanction.This is why Orion sometimes stops reckless pirates, terrorists, or cults. Not because they are moral, but because they are bad for business.II. A Recognized Debt Is SacredIf the Accord witnesses a contract, the debt must be paid. Failure to pay is not merely breach of contract. It is sacrilege against the compact.Debts can be paid in money, service, blood, territory, silence, or names.III. Names Are PropertyIdentity is a negotiable asset. False names, noble lineages, ship registries, gene records, and citizenship files can be bought, sold, inherited, or revoked.Stealing an Accord-protected identity is treated like grand theft.Destroying one may be treated like murder.IV. Do Not Hunt Another Hunter Without LeaveMembers may not assassinate, expose, or ruin one another without arbitration.This does not prevent conflict. It makes conflict procedural.V. The Guide Is NeutralGuides, underworld judges, and recognized brokers may not be harmed while conducting Accord business.Breaking this article is one of the fastest ways to trigger a Scorpion Protocol.VI. The Stars RememberAll major agreements are recorded somewhere. The existence of the record may be hidden, but the Accord believes no meaningful transaction should ever truly vanish.This article is the philosophical basis for the Accord’s blackmail culture.VII. No Hunter Is Greater Than the HuntIf a member becomes an existential threat to the Accord, the Accord may name that member Orion Fallen.At that point the Scorpion Protocol may be invoked.Major Orion DivisionsThe Poseidon FleetNamed for Orion’s divine father in some traditions, the Poseidon Fleet controls illegal movement.It is less a fleet than a distributed maritime and starship logistics empire. Its captains specialize in routes that conventional authorities find difficult to monitor.They use: Ocean-world submersible ports. Gas giant refueling shadows. Misfiled naval tenders. Salvage claims. Belter habitats. Corporate freeports. Abandoned scout stations. Old war caches. Misjump recovery myths. Emergency medical transports as cover.Their internal boast is: “Orion walks on water. We walk between worlds.”Poseidon captains are often romanticized by lower-ranking criminals. Some are flamboyant privateers. Others are meticulous freight accountants with bloodless manners.Artemis considers the Poseidon Fleet the Accord’s circulatory system. Cut it, and Orion starves.The Oenopion DivisionThe Oenopion Division handles blindness.That means forgery, legal sabotage, false evidence, erased files, memory manipulation, witness corruption, sensor spoofing, and bureaucratic misdirection.Its name comes from the king who, in myth, blinds Orion. The Division’s private joke is that they learned from the wound.Their creed: “A dead enemy is a problem solved once. A blind enemy solves problems for you.”They do not just hide crimes. They make investigators believe the wrong story.Typical Oenopion operations include: Replacing cargo manifests with mutually contradictory but plausible versions. Creating false noble genealogies. Planting evidence that implicates a rival syndicate. Engineering audit trails that lead to dead agents. Generating synthetic eyewitnesses. Creating fake xboat traffic histories. Erasing a person from medical, tax, and travel records. Making an honest customs inspector appear corrupt.Oenopion specialists are among the most hated people in Artemis. They are why Artemis rarely trusts a single piece of evidence.The Merope NetworkThe Merope Network specializes in desire.It handles social engineering, elite compromise, marriage contracts, romantic manipulation, court gossip, artistic patronage, vice markets, and diplomatic seduction.Merope operatives are not simply “honey traps.” The best of them never need sex, beauty, or blackmail. They understand loneliness, ambition, shame, vanity, grief, and the desperate hunger to be seen.They compromise people by offering exactly what the target believes they deserve.A Merope operation may involve: A patronage circle for neglected noble spouses. An illegal dueling club for bored heirs. A philosophical salon seeded with controlled rumors. A luxury clinic that records genetic secrets. A matchmaking service for dynastic families. A cultural foundation funding dissident artists. A grief-support network for families of naval casualties. A private school that quietly sorts future assets.The Merope Network is especially dangerous because many of its relationships begin as sincere. Its operatives often become emotionally entangled, and some become double agents for love, guilt, or revenge.Artemis calls Merope cases silver wounds: compromises that look clean until they start bleeding.The Eos InitiativeEos, the dawn, is associated with abduction, desire, renewal, and the beginning of pursuit. In Orion lore, the Eos Initiative recruits people at the moment their old life ends.It looks for: Disgraced officers. Bankrupt merchants. Exiled nobles. Failed revolutionaries. Orphaned ship crews. Former intelligence assets. People betrayed by Imperial institutions. Criminals who are too talented to waste. Survivors of scandals the Empire covered up.Eos recruiters do not lead with threats. They lead with recognition.Their favorite line is: “The Empire used you. We will pay you.”The Eos Initiative is why the Accord keeps replenishing itself. Artemis can destroy a cell, arrest a Guide, or seize ships, but so long as the Empire produces embittered, talented, abandoned people, Eos has raw material.Some Artemis officers privately admit that Eos is not entirely wrong.That admission is dangerous.The Bellatrix HousesBellatrix is one of Orion’s bright stars, later associated by name with warlike imagery. In the Accord, Bellatrix Houses are elite violence salons.They are not common assassins. They are finishing schools for people who kill in politically meaningful ways.Bellatrix Houses train: Duelists. Noble bodyguards. Hostage recovery specialists. Assassins. Counter-assassins. Boarding team leaders. Close protection details. Ceremonial killers for vendetta contracts.A Bellatrix graduate is expected to understand etiquette, law, poetry, weapons, and timing.They do not merely ask, “Can this person be killed?”They ask: “What will the killing say?”An Alnitak Beltmaster often draws from Bellatrix when a death must be understood as a message.The Rigel LineThe Rigel Line is the Accord’s courier and extraction network.Rigel operatives specialize in impossible movement: getting people, cargo, or data across borders that should be sealed. They use passenger liners, tramp freighters, diplomatic pouches, frozen embryos, religious pilgrimages, medical evacuations, salvage drones, and misregistered smallcraft.A Rigel courier is judged by two standards: The package arrives. No one understands how.Their motto: “The foot leaves no wound.”Artemis hates the Rigel Line because it turns victory into rumor. A target is surrounded, warrants are issued, ships are locked down, and then the target is simply gone.The Betelgeuse CompactBetelgeuse is the red shoulder of Orion. The Betelgeuse Compact is not a formal division but a faction within the Accord: older, bloodier, more romantic, and more violent.They believe the Accord has grown too cautious. They argue that Orion should not merely profit from the Imperial order, but dominate it from the shadows.Betelgeuse members favor: Spectacular reprisal. Pirate kings. Noble humiliation. Open corruption. Military-grade theft. Public demonstrations of impunity.They are useful in war and dangerous in peace.Artemis sometimes covertly encourages Betelgeuse recklessness because it makes Orion visible. Mintaka and Alnilam usually prefer to restrain them.The Pleiades VaultsIn myth, Orion is sometimes said to pursue the Pleiades. In Accord mythology, the Pleiades Vaults are seven hidden archives containing the Accord’s most dangerous leverage.Each Vault supposedly contains a different class of secret: Noble bloodlines. Imperial intelligence crimes. Megacorporate illegal research. Naval procurement fraud. Blackmail on subsector courts. Identities of deep-cover Orion assets. The truth of Project First Hunt.No one knows whether all seven are real.The phrase “Orion still hunts the Seven Sisters” means the Accord is searching for one of its own lost archives. The phrase “one sister has gone dark” means a Vault has been compromised.An entire campaign could revolve around one Pleiades Vault.The Scorpion ProtocolThe Scorpion Protocol is the Accord’s most feared internal mechanism.It is invoked when a member becomes so dangerous, reckless, disloyal, or exposed that their continued existence threatens the Accord itself.Once invoked, the target is declared Orion Fallen.At that moment, every debt owed to the target is suspended. Every safe house is closed. Every account is frozen. Every alias is burned. Former allies are permitted, and sometimes required, to betray them.The Protocol has four stages.I. ShadowThe target is quietly isolated.Their calls are delayed. Their money moves slowly. Their usual contacts vanish. Their ship receives inconvenient maintenance holds. Their lovers are warned away. Their enemies receive anonymous tips.At this stage, the target may still submit to arbitration.II. VenomThe Accord begins poisoning the target’s life.Their secrets leak. Their crews mutiny. Their forged identities fail. Local police receive evidence. Rival criminals are given permission to collect old debts.At this stage, survival is still possible, but recovery is rare.III. StingDirect action is authorized.A Bellatrix killer, Poseidon boarding crew, or betrayed subordinate is assigned to end the matter.The Accord prefers elegant deaths: airlock accident, duel, overdose, misjump, surgical complication, suicide note, pirate raid.The method should close questions, not open them.IV. Black SkyIf the target survives Sting, the Accord treats the matter as existential.The Star Council may authorize mass exposure, orbital-scale violence, noble ruin, or the destruction of entire facilities. Black Sky is rare because it risks everything Article I exists to prevent.Artemis watches for Scorpion activity because it reveals the Accord’s internal fault lines.The irony is deliberate: Orion fears the Scorpion more than Artemis.Orion CultureInitiation: The Blindfold of ChiosA new Hunter is blindfolded and taken through a route they cannot reconstruct. They are seated before unseen witnesses and asked three questions: What did the Empire take from you? What are you willing to hunt? What name will you leave behind?Then they are given a task. It may be theft, deception, delivery, sabotage, or betrayal. Murder is not required and is sometimes considered crude.When they return, the blindfold is removed. The lesson is that everyone begins blind. The Accord gives sight, but only after obedience.The First QuarryEvery Hunter is expected to identify and cultivate a Quarry within their first year.This can be a customs clerk, naval technician, banker, court secretary, port medic, entertainer, or family member of someone useful.The Quarry is a test of patience. Brute intimidation is considered amateur work. The best Quarry never realizes they were hunted until the trap has already closed.The Feast of the Rising HunterOn worlds where Orion’s constellation is visible, some cells hold a private feast when Orion first rises in the local night sky.The ritual varies. In sophisticated circles, it is a masked dinner. Among pirates, it may be a drunken oath-taking. Among old Project First Hunt descendants, it resembles a memorial service.Common elements: Three lights are placed in a line. A black cup is passed. The names of dead Hunters are spoken. A debt is forgiven. A new debt is created. Someone tells the story of the Blinding.Artemis sometimes schedules raids around these feasts.The Accord knows this.Sometimes the feast is bait.Public Faces of the Orion AccordThe Accord rarely appears under its own name. It operates through respectable fronts.Examples:Accordance LogisticsA freight consultancy that specializes in “difficult customs environments.” It is a Poseidon Fleet clearinghouse.Chios Risk InstrumentsA boutique insurer that quietly launders ransoms, cargo fraud, and piracy payments. It is tied to Oenopion and Mintaka.Dawnward FoundationA charity for displaced spacers, disgraced veterans, and frontier disaster survivors. It is an Eos recruitment pipeline.Three Star ArbitrationA private commercial dispute-resolution firm used by corporations that do not want court discovery. It is an Accord tribunal.Merope Cultural TrustA patronage network for artists, scholars, salons, and noble retreats. It is a social compromise engine.Bellatrix Security CollegeA legal bodyguard and executive protection academy. It also trains assassins.Weaknesses of the Orion AccordThe Accord is powerful, but not invincible.Its weaknesses are thematic.PrideOrion members often believe they are smarter than lawful institutions. Many are. Not all are.RitualThe Accord’s mythic habits create patterns. Artemis exploits those patterns mercilessly.Arbitration DependencyThe Accord works because criminals trust its dispute-resolution mechanisms. If Artemis can corrupt, expose, or fake Accord arbitration, criminal trust begins to collapse.Old Imperial RootsSome Orion systems still use architecture descended from Project First Hunt. Artemis has partial legacy access.Fear of ExposureThe Accord’s greatest shield is ambiguity. Once a local government, noble house, or naval command understands that scattered crimes are one structure, Orion becomes vulnerable.Scorpion ParanoiaEvery senior Orion figure fears being named Orion Fallen. Artemis can weaponize that fear by making leaders think the Protocol is already moving against them.Key Orion NPCs“Mintaka” — The White AccountantA perfectly polite financial criminal who never raises their voice. Mintaka can ruin a world without firing a shot by calling in debts, collapsing insurance, freezing payroll systems, and exposing illegal loans.Public identity: senior partner at a legitimate interstellar risk firm.Private goal: keep Orion profitable and quiet.Secret: Mintaka has been feeding limited information to Artemis to weaken Betelgeuse extremists.Use at the table: the charming devil who can offer the PCs money, legitimacy, and protection.“Alnitak” — The Red ShoulderA former naval boarding officer turned underworld warlord. Alnitak believes violence is most effective when it is theatrical enough to prevent future resistance.Public identity: private security magnate.Private goal: restore fear of the Accord.Secret: Alnitak wants to provoke a limited war with Artemis to identify Imperial moles.Use at the table: the enemy who respects courage and punishes insult.“Alnilam” — The Listener in the MiddleThe least visible Beltmaster. Alnilam trades in secrets, not money or blood. No confirmed image exists. Some believe Alnilam is a person. Others believe Alnilam is a distributed intelligence built from old Imperial systems.Public identity: unknown.Private goal: preserve the Pleiades Vaults.Secret: Alnilam knows the true origin of Artemis.Use at the table: the voice that contacts the PCs through impossible channels.The Blind KingHead of an Oenopion cell. Once an Imperial records magistrate, now a master of evidence manipulation.Public identity: retired legal scholar.Private goal: prove that reality is just paperwork with witnesses.Secret: genuinely hates murder and considers killers intellectually lazy.Use at the table: the villain who can erase the PCs’ ship, licenses, citizenship, or criminal charges depending on whether he likes them.Lady Merope ValeA noble patron, salon hostess, and emotional predator. She knows which heirs hate their fathers, which admirals are lonely, which priests doubt their faith, and which corporate officers need absolution.Public identity: philanthropist and cultural patron.Private goal: make the next generation of subsector leadership emotionally dependent on her circle.Secret: one of her romantic compromises became real, and Artemis knows it.Use at the table: someone who can help the PCs socially while making them feel seen in ways that are dangerous.Captain Tidal GravesA Poseidon Fleet commander whose ships specialize in ocean-world extraction and gas giant shadow refueling.Public identity: salvage operator.Private goal: keep the routes open.Secret: has a personal code against trafficking children, prisoners, or unwilling passengers. This puts him at odds with Betelgeuse clients.Use at the table: a criminal ally the PCs may actually like.Dawn-EyesAn Eos recruiter who appears after disasters, scandals, failed missions, and betrayals.Public identity: humanitarian relief coordinator.Private goal: recruit the wounded before Artemis can protect them.Secret: was once an Artemis Ranger left behind during a denied operation.Use at the table: the tempter who offers the PCs a way out when lawful society fails them.The Artemis Working GroupCore IdentityThe Artemis Working Group is an interagency Imperial intelligence task force created to counter the Orion Accord.It is intentionally not a bureau, service, or ministry.It is a working group because a working group can cross boundaries that formal agencies cannot. It borrows authority. It borrows personnel. It borrows ships. It borrows budgets. It borrows jurisdiction. Then it vanishes back into paperwork.To the public, Artemis does not exist.To most Imperial officials, Artemis is a rumor attached to sealed warrants and strange interdepartmental requisitions.To Orion, Artemis is the only Imperial enemy that understands the hunt.Its motto: “One arrow. One truth.”Its informal field saying: “Do not chase the hunter. Find what he cannot stop hunting.”Artemis OriginAfter Project First Hunt became the Orion Accord, the Imperium faced an impossible problem.It could not openly admit that Imperial Intelligence had helped create a trans-subsector criminal compact. Public exposure would ruin noble careers, invalidate court cases, destabilize frontier governments, and reveal old covert methods.So the response had to be deniable.The first Artemis cell was created under a bland administrative heading: Interagency Commercial Irregularities Working Group 12.Its initial mandate was narrow: recover records from Project First Hunt.Its real mandate was broader: Identify surviving Orion infrastructure. Prevent exposure of Imperial involvement. Neutralize defected assets. Recover blackmail archives. Destroy the Accord if possible. Control the truth if destruction failed.Over time, Artemis changed. Its younger members were not responsible for the original sin. Many joined because Orion destroyed lives, corrupted worlds, and made law look foolish. Artemis became less cover-up and more crusade.But the cover-up remains buried in its foundation.That contradiction should haunt the organization.Artemis Self-MythArtemis teaches a different Orion myth.In its version, Orion was a mighty hunter who mistook strength for license. He boasted that he could kill every beast of the Earth. Whether through Gaia, Artemis, Apollo, or the Scorpion, the world answered him.The lesson is: “No predator is larger than the world that contains him.”Artemis officers do not see themselves as police. They are guardians of the boundary.Civilization can tolerate vice, smuggling, bribery, and local corruption. It cannot tolerate a predatory order that places itself above law, sovereignty, and personhood.Their task is not vengeance.Their task is balance.At least, that is what they tell themselves.Artemis StructureTrackersTrackers are analysts, auditors, signal interpreters, linguists, accountants, customs specialists, and historians.They find the trail.A Tracker may spend six months studying freight irregularities before identifying one suspicious cargo pattern. They may reconstruct a criminal route from fuel purchases, marriage records, medical imports, and missing spare parts.Trackers are often underestimated because they do not look dangerous.Artemis considers them sacred.A dead Tracker usually means Orion has begun to understand the investigation.RangersRangers are field operatives.They conduct surveillance, infiltrate starports, follow suspects, handle informants, enter dangerous places under false names, and survive long enough to report what they find.A Ranger needs patience more than courage. They must watch predators without flinching and without being seen watching.Rangers often have the highest psychological casualty rate in Artemis because they live closest to Orion’s seductions.ArchersArchers are case officers and operation planners.They decide where to aim.An Archer’s job is not to gather every fact. It is to identify the one fact, person, transaction, ship, or secret that will collapse the larger structure.A good Archer does not raid ten warehouses.A good Archer makes ten warehouses useless.HuntmastersHuntmasters command campaigns.A campaign may target a single Orion Guide, a Poseidon route, a Merope compromise network, or an entire subsector-level Accord structure.Huntmasters manage relations with local nobles, naval commands, courts, ministries, and sometimes journalists. They are part intelligence officer, part prosecutor, part diplomat, and part priest.A Huntmaster who becomes obsessed with one target is quietly removed.In theory.The Silver BowThe Silver Bow is the executive council of Artemis.It has five seats, each representing a discipline.The EyeSurveillance, reconnaissance, and observation.The HandField operations and direct action.The TongueHuman intelligence, informants, social infiltration.The LedgerFinance, trade, contracts, and economic warfare.The VeilCounterintelligence, secrecy, and internal discipline.The Silver Bow rarely meets physically. Its members may not know one another’s true identities. Decisions are issued as hunt authorizations.A full Silver Bow authorization is called a drawn bow.Once the bow is drawn, someone important is going to fall.Artemis DoctrinePredator EcologyArtemis does not ask only, “Who committed the crime?”It asks: Who profited? Who protected it? Who moved the cargo? Who forged the papers? Who laundered the debt? Who supplied the ship? Who looked away? Who was compromised? Who will replace the criminal if this one dies?This is called predator ecology.An ordinary police agency arrests the smuggler.Artemis identifies the port official, the false insurer, the bank node, the noble patron, the data broker, the shipyard, the customs algorithm, and the social leverage that made the smuggling sustainable.Then it chooses one arrow.The One-Arrow PrincipleArtemis prefers operations where a single action causes systemic collapse.Examples: Arresting a low-level courier whose testimony invalidates a hundred false manifests. Freezing one insurance instrument that strands six pirate crews. Leaking one noble scandal that causes Orion patrons to abandon a Guide. Seizing one data vault that destroys trust in Accord arbitration. Turning one Merope operative who knows which marriages are compromised. Exposing one Oenopion forgery method so thousands of documents become suspect.The One-Arrow Principle makes Artemis seem inactive for long periods. Local authorities may think they are doing nothing.Then a whole criminal ecosystem dies in a week.The Silver VowArtemis officers swear an internal oath called the Silver Vow.The Vow has three renunciations: No profit from the hunt. No glory from the hunt. No love of the hunt.The third is the hardest.Artemis fears officers who begin to enjoy hunting Orion. Enjoyment leads to rivalry. Rivalry leads to obsession. Obsession makes the officer predictable.Predictability is how Orion kills you.Artemis SubgroupsThe Apollo OfficeThe Apollo Office is Artemis’s strategic analysis and predictive intelligence branch.Apollo sees farther than Artemis but is less trusted.It uses statistics, old intelligence archives, psychological models, traffic histories, noble genealogies, market distortions, and sometimes morally questionable simulations to predict Orion moves.Apollo analysts often manipulate Artemis field teams by withholding context. Their defense is simple: if the Archer knows too much, the Archer becomes readable.Apollo’s motto: “Light before arrow.”Artemis’s private complaint: “Apollo always tells the truth after it matters.”Campaign role: Apollo is the ally who gives useful information in the most infuriating possible way. It may also be using the PCs as bait.The Selene NetworkSelene is moonlight, reflection, and patient observation.The Selene Network handles orbital surveillance, passive sensor grids, traffic metadata, port shadowing, and long-duration observation.Selene does not chase. Selene watches.Its assets include: Quiet satellites. Maintenance drones. Port traffic models. Refueling logs. Dockworker rumor feeds. Shipyard telemetry. Long-lens observation posts. Passive emissions buoys. “Dead” weather satellites. Naval systems no longer listed as active.A Selene file may contain years of seemingly meaningless observations. Then a Tracker notices that the same maintenance drone is present near three unrelated ship disappearances.That is the trail.The Hecate CellHecate is crossroads, thresholds, ghosts, magic, and night roads.The Hecate Cell handles deep cover, false identities, illegal border crossing, forbidden tradecraft, and operations that Artemis will later deny.Hecate agents specialize in becoming the sort of people Orion wants.A Hecate cover identity may take years to mature. Some agents live as criminals so convincingly that even Artemis handlers worry whether the cover is still a cover.Hecate has three internal rules: Always leave yourself a crossroads. Never trust a door that opens only one way. If your handler cannot extract you, your name was already dead.Campaign role: Hecate is perfect for morally ambiguous PCs. They may be asked to carry a false identity, protect an undercover agent, or discover that someone they trusted is Hecate.The Gaia ProgramGaia represents the world itself.The Gaia Program studies logistics, environments, and material dependencies. It asks where Orion physically lives.No criminal empire survives on secrets alone. Ships need fuel. Crews need food. Weapons need parts. Clones need vats. Drugs need precursors. Bribes need banks. Safe houses need plumbing. Pirates need shore leave.Gaia finds the material roots.Typical Gaia questions: Which worlds import more ship parts than their registered fleets require? Which starports sell fuel that never appears on legal manifests? Which agricultural shipments mask biotic contraband? Which mining habitats report impossible population changes? Which noble estates consume enough medical supplies to support hidden prisoners? Which religious pilgrimage route is actually a courier channel?Gaia’s internal maxim: “The hunter still leaves footprints.”Campaign role: Gaia gives the PCs grounded investigative missions: inspect cargo, trace fuel, follow food shipments, audit life-support parts.The Scorpion UnitThe Scorpion Unit is Artemis’s direct-action arm.It exists for targets that cannot be arrested, exposed, or turned.Its existence is controversial because it mirrors Orion’s own Scorpion Protocol. Artemis officially uses Scorpion only when lawful structures cannot safely contain the threat. In practice, “cannot safely contain” is a phrase with dangerous flexibility.Scorpion operators are quiet, disciplined, and rarely dramatic. They are trained to end a threat without producing a legend.Their motto: “No song for the sting.”Some Huntmasters despise them. Others rely on them too often.Campaign role: Scorpion can be a terrifying ally, a rival team, or the sign that Artemis has decided the situation is beyond courts.The HoundsThe Hounds are behavioral profilers and pattern analysts.They track habits: favorite ports, repeated lovers, preferred lies, stress responses, payment rituals, revenge patterns, and the emotional signatures of criminal cells.A Hound does not ask, “Where is the target?”A Hound asks: “What does the target need to do in order to still feel like themselves?”That question catches people.The Hounds are especially effective against Orion because the Accord’s mythology encourages members to repeat symbolic behavior.Campaign role: a Hound can profile the PCs, unsettle them, and correctly infer things they never said aloud.The Brauron HousesArtemis is not only goddess of the hunt. She is also a protector of children and the vulnerable.The Brauron Houses are secret safe-house networks for witnesses, defectors, families of informants, trafficked persons, and children threatened by Orion retaliation.They are among the few Artemis programs with a clear moral purpose.They are also security nightmares.Orion knows that Artemis will risk much to protect Brauron locations. This makes them targets, bait, and moral pressure points.Campaign role: protecting a Brauron House is a strong mission for PCs who need to see why Artemis matters.The Actaeon FileIn myth, Actaeon sees Artemis unveiled and is destroyed by his own hounds.In Artemis usage, an Actaeon File is opened when someone has seen something they were not meant to see.This may include: An honest police officer who discovers Artemis. A journalist who finds Project First Hunt records. A noble who learns Orion was Imperial-created. A PC who sees both sides of the secret war. An Artemis officer who uncovers internal corruption. An Orion member who identifies a Silver Bow seat.An Actaeon File does not automatically mean execution. It means the person has become a containment problem.Possible resolutions include recruitment, memory alteration, discrediting, protective custody, false death, blackmail, or elimination.Campaign role: the PCs may become an Actaeon File.The Iphigenia ClauseThis is Artemis’s darkest internal doctrine.Named for mythic sacrifice before a great campaign, the Iphigenia Clause allows Artemis to sacrifice an asset, operation, reputation, or innocent opportunity in order to preserve a larger hunt.Officially, it is almost never invoked.Unofficially, every Huntmaster knows the temptation.Examples: Letting a smuggling shipment pass to preserve a deeper cover. Allowing one corrupt noble to escape to expose three others. Abandoning an undercover agent rather than reveal Artemis. Permitting Orion to kill a known traitor whose death will reveal a route. Framing a dead criminal for crimes they did commit, plus one they did not, to hide an operation.The Iphigenia Clause is where Artemis can become monstrous.Campaign role: force the PCs to decide whether Artemis’s patience is wisdom or cowardice.Artemis Public CoversCommercial Irregularities BoardA dull-sounding investigative panel used to access trade records.Customs Harmonization ReviewA bureaucratic excuse to audit starport procedures and freight manifests.Anti-Piracy Liaison CellA cover for joint Navy-Artemis operations.Frontier Witness Relocation OfficeA Brauron House administrative mask.Naval Procurement Fraud InquiryOften used by Gaia and Ledger personnel to examine ship parts, fuel, and weapons contracts.Cultural Security AssessmentA cover used to investigate Merope salons, schools, and noble gatherings.Weaknesses of ArtemisCompartmentalizationArtemis protects itself by limiting knowledge. This means field teams often do not know why a mission matters.That saves secrets.It also gets people killed.Political FragilityBecause Artemis is a working group, not a formal ministry, powerful nobles can interfere by attacking its borrowed authorities.A local duke may not be able to abolish Artemis, but they can deny port access, challenge warrants, withhold naval escorts, or demand personnel reassignment.Moral InjuryArtemis officers are asked to watch crimes continue while they build larger cases. Some break. Some defect. Some decide Orion’s honesty is preferable to Imperial hypocrisy.Apollo ManipulationThe Apollo Office sometimes uses people as variables. This can produce brilliant results and deep resentment.Scorpion ContaminationEvery time Artemis uses direct assassination, it becomes easier to use again.Orion understands this and tries to force Artemis into Scorpion choices.The Founding LieIf the public learns that Orion grew from an Imperial intelligence operation, Artemis could be crippled by scandal.Some within Artemis believe the truth must eventually come out.Others would kill to keep it buried.Key Artemis NPCsHuntmaster Selene ArmandA calm, elegant campaign commander known for waiting months before acting. She never raises her voice. She treats criminal networks like weather systems.Public identity: senior customs liaison.Private goal: dismantle the Poseidon Fleet in her subsector.Secret: she once allowed a Poseidon ship to escape because it carried children Orion was evacuating from a war zone.Use at the table: the patron who gives the PCs strange, limited tasks that later prove devastating.Director Cynth Vale, Seat of the EyeA member of the Silver Bow. “Cynth” is probably not her real name. She controls surveillance authorizations and Selene assets.Public identity: unknown.Private goal: identify the Star Council’s living members.Secret: she believes one Star Council seat is an Imperial intelligence legacy system, not a person.Use at the table: the remote authority whose decisions arrive as sealed orders.Maro Ionescu, Apollo AnalystBrilliant, cold, and socially unsettling. Maro predicts criminal behavior with disturbing accuracy but often refuses to explain the model.Public identity: naval strategic consultant.Private goal: force Orion into triggering its own Scorpion Protocol against the wrong person.Secret: Maro has identified a likely Artemis mole but is allowing the mole to continue operating for predictive value.Use at the table: the person who gives the PCs exactly enough truth to be useful and not enough to feel safe.Agent Kallisto RenA Hecate deep-cover operative embedded in the Merope Network.Public identity: social fixer and private tutor for noble families.Private goal: reach Lady Merope Vale’s inner circle.Secret: Kallisto has fallen in love with one of her targets, or has convinced herself that the feeling is only cover.Use at the table: the compromised ally whose rescue may destroy years of work.Commander Pike “Sting” VarrasLeader of a Scorpion Unit team.Public identity: retired Marine security contractor.Private goal: end threats cleanly before more civilians die.Secret: Orion once tried to recruit him after Artemis abandoned his team during a denied operation.Use at the table: the hard man who may be right for the wrong reasons.Dr. Hestia MornA Gaia Program logistics savant.Public identity: academic economist studying frontier trade inefficiencies.Private goal: prove that Orion can be starved without mass arrests.Secret: she has discovered that several worlds depend on Orion-controlled logistics for essential medicines.Use at the table: the person who reveals that destroying Orion too quickly could kill innocents.The Little BearA young Tracker trainee assigned to a Brauron House after surviving Orion retaliation.Public identity: refugee child or junior clerk.Private goal: become Artemis.Secret: has memorized part of a Pleiades Vault without understanding it.Use at the table: the vulnerable NPC both sides need alive.The Secret Shared HistoryAt the highest levels, both Orion and Artemis know fragments of the same buried truth.Neither side has the whole story.The First HunterThe original commander of Project First Hunt is remembered only by title: the First Hunter.Orion claims the First Hunter saw the truth before anyone else: that the Empire’s law was a costume, and real order came from enforceable debt.Artemis claims the First Hunter tried to shut the project down after realizing it had become criminal.A third possibility is more interesting:The First Hunter deliberately split the project.One half became Orion, to control the underworld.One half became Artemis, to control Orion.If true, the war itself may be part of the original design.That makes the campaign much stranger.The Black Star LedgerSomewhere there is an archive called the Black Star Ledger.It allegedly contains: Names of the original Imperial officers who founded Project First Hunt. Identities of the first Orion defectors. Evidence that early Artemis operations protected Imperial reputations. Proof that certain noble houses funded both sides. The original command protocols for Accord identity stones. A list of agents who were never recalled. A final message from the First Hunter.Orion wants the Ledger because it can blackmail the Imperium.Artemis wants it because it can destroy the Accord, or destroy Artemis.Apollo may already have part of it.Alnilam may be built from it.The PCs may accidentally transport it.How Orion and Artemis View Each OtherOrion’s View of ArtemisTo Orion, Artemis is not justice.Artemis is the Empire’s guilty conscience with a knife.Common Orion sayings: “Artemis only hunts what the Emperor cannot tax.” “The silver bow is still Imperial steel.” “They call us predators because they hate competition.”Orion respects Artemis more than ordinary police. A Hunter who survives Artemis attention gains status. A Guide who fools Artemis earns mythic prestige.But there is fear under the respect.Artemis is patient in a way criminals find unnatural.Artemis’s View of OrionTo Artemis, Orion is not romance, rebellion, or frontier freedom.Orion is organized predation.Common Artemis sayings: “A smuggler avoids law. Orion replaces it.” “Do not admire the hunter from inside his trophy room.” “Every Accord contract is a border drawn around someone weaker.”Artemis officers are trained not to be seduced by Orion’s elegance. The Accord will always offer a better story: more loyalty, more honesty, more gratitude, more reward.That is part of the trap.The Current ConflictAt the campaign’s start, the cold war between Orion and Artemis has entered a dangerous phase.Three things have changed.1. A Pleiades Vault Has SurfacedSomeone found part of one of the seven legendary archives.No one knows which Vault it is.The data may be incomplete, corrupted, or intentionally seeded. But it is enough to make Orion nervous and Artemis reckless.Possible location: hidden inside a ship’s old black box, a noble family archive, a derelict scout base, a monastery database, or the memory of a courier who does not know what they carry.2. The Betelgeuse Compact Wants WarA violent Orion faction believes subtlety has made the Accord weak. They want to bloody Artemis publicly, humiliate Imperial authority, and prove that the frontier belongs to hunters.They may stage a spectacular attack and blame a rival faction.They may target a Brauron House.They may assassinate a minor noble under Artemis protection.They may try to force the Accord to invoke Black Sky.3. Artemis Suspects a Silver Bow LeakSomeone inside Artemis is feeding Orion enough information to avoid catastrophe, but not enough to expose themselves.Possibilities: A true Orion mole. An Apollo-controlled false leak. A Silver Bow member protecting the founding secret. A Hecate agent whose cover has inverted. An old Project First Hunt system still obeying legacy commands. One of the PCs, unknowingly, through compromised gear or contacts.This means Artemis may hire outsiders because it cannot fully trust itself.That gives the PCs a perfect entry point.Campaign UseStarting SituationThe PCs are a crew with a ship, debts, skills, and just enough independence to be useful.They receive a job that looks ordinary: Move sealed cargo. Extract a passenger. Inspect a derelict. Deliver a diplomatic pouch. Transport a witness. Recover a stolen identity stone. Carry medical supplies to a restricted world. Investigate why a freighter vanished.The job touches Orion.Then Artemis notices.Now the PCs are not just doing a job. They are standing between two hunters.Campaign Escalation ClockUse this as a loose campaign structure.Phase 1: SpoorThe PCs encounter signs of the Accord without knowing what they mean.Clues: Three-star symbols. Strange freight irregularities. A polite criminal who honors a debt. A forged identity that is too good. A customs official afraid of a black gemstone. A ship that disappears from port records.Artemis appears only as a distant pressure: sealed questions, odd inspections, or a stranger watching from the concourse.Phase 2: The First ArrowArtemis contacts the PCs.The offer may be legal, coercive, or desperate.Possibilities: “Carry this tracker and do not open the case.” “Tell us who hired you and we erase the customs violation.” “Your passenger is not who they say they are.” “That gemstone is an Accord credential.” “We need your ship because our own assets are compromised.”The PCs learn the Orion Accord is real.Phase 3: The GuideThe PCs meet an Orion Guide.The Guide is helpful, civilized, and dangerous. They offer a counter-narrative: Artemis lies, the Empire uses people, Orion pays debts, and the PCs have already broken laws whether they admit it or not.This is where Orion should become tempting.Do not make the Accord stupidly evil too early. Let the players feel why people join.Phase 4: The Silver WoundA Merope or Oenopion operation compromises someone close to the PCs.A patron, ally, family member, noble contact, or shipmate becomes leverage.The conflict turns personal.The PCs must decide whether to trust Artemis protection, Orion negotiation, or their own plan.Phase 5: The Scorpion MovesSomeone is declared Orion Fallen.It might be an NPC ally, a PC patron, or eventually one of the PCs.The underworld turns against the target. Safe houses vanish. Money disappears. False charges appear. Friends stop answering.The PCs see how terrifying Orion is when its rules become weapons.Phase 6: The Black Star LedgerThe founding secret emerges.The PCs obtain, decode, steal, or become the only witnesses to evidence that Orion and Artemis share an origin.Now the campaign is no longer cops versus criminals.It is about who gets to define truth.Phase 7: The Drawn BowThe Silver Bow authorizes a decisive campaign.Artemis may attempt to destroy the local Accord structure in one massive operation.Orion may respond by invoking Black Sky.The PCs can choose to help Artemis, help Orion, expose both, protect innocents, seize the Ledger, or create a third path.Adventure Hooks1. The Black Stone PassengerA passenger dies aboard the PCs’ ship during jump. Among their belongings is a Black Star Stone.When the ship exits jump, three groups are waiting: Local police with a murder warrant. Orion operatives claiming the stone is theirs. Artemis agents insisting the passenger was under Imperial protection.The stone contains only one useful thing: coordinates to a place no one admits exists.2. The Feast That Was BaitThe PCs are hired to provide security for an elite private dinner. They slowly realize it is a Feast of the Rising Hunter.Then Artemis raids it.Then the PCs realize Artemis raided the wrong feast.The real meeting is elsewhere, and this one was designed to expose Artemis methods.3. The Blind ManifestA cargo manifest implicates the PCs in smuggling weapons to rebels.They did not do it.The forgery is perfect because the Oenopion Division did not merely fake the records; it rewrote the surrounding reality. Port cameras, dockworker testimony, fuel logs, and maintenance data all agree.To clear themselves, the PCs must find the one person the forgery could not account for.4. The Brauron HouseArtemis hires the PCs to transport refugees from a compromised safe house.One refugee is a child who knows part of a Pleiades Vault.One refugee is an Orion plant.One Artemis officer believes the group should be sacrificed to preserve a larger operation.5. The Poseidon RouteA world is suffering medical shortages because legal supply chains have failed. The only functioning route is controlled by the Poseidon Fleet.Artemis wants the route mapped and destroyed.The local population needs the route to survive.Orion offers to keep the medicine flowing in exchange for formal local dependence.The PCs must decide whether law, survival, or independence matters most.6. Orion FallenA former Orion Guide begs the PCs for extraction. They have been named Orion Fallen and claim to possess evidence that can expose a Star Council seat.The Accord wants them dead.Artemis wants them alive.Apollo wants them moving.The Guide may be lying, but the Scorpion Protocol is definitely real.7. The Merope MarriageA noble wedding is actually an Accord operation to fuse two compromised houses. Artemis wants the PCs to identify which member of the wedding party is the Merope operative.Complications: The bride knows and approves. The groom is an Artemis informant. The officiant is Orion. The dowry contains a Pleiades key. The marriage may prevent a subsector war.8. The Apollo BetrayalThe PCs discover that an Apollo analyst has been feeding them missions designed to provoke a particular Orion response.Every job they completed was real.Every person they saved mattered.But they were also bait.Now Orion believes the PCs are Artemis assets, and Artemis is not sure they are controllable.9. The First Hunter’s TombA derelict station contains the preserved command archive of Project First Hunt.Orion calls it a shrine.Artemis calls it evidence.A third faction calls it a weapon.The station’s old systems recognize both Orion stones and Artemis clearance phrases.That should be impossible unless both descend from the same root.10. Scorpion Against ScorpionOrion’s Scorpion Protocol and Artemis’s Scorpion Unit target the same person on the same night.The PCs are hired to protect, kill, extract, or identify that person.The twist: the target is not a criminal. They are the last living witness to the original split.Rumors TableRoll or choose. “The Orion Accord isn’t real. It’s what criminals say when they want to sound important.” “Three taps on a table will get you killed in some ports.” “There’s a customs auditor on Regina Station who can make your ship vanish from Imperial records.” “Artemis agents don’t carry badges. They carry warrants that haven’t been written yet.” “The Accord never breaks a contract. That’s what makes them worse.” “A black stone with three stars is worth more than a ship if you know who to show it to.” “The Poseidon Fleet can move cargo through a naval blockade.” “Merope doesn’t blackmail people. Merope makes people grateful to be owned.” “The Scorpion Protocol is just underworld theater. Unless you hear your own name.” “Artemis once let an entire pirate crew escape because they were following the money.” “There are seven Vaults. One of them contains the name of an Emperor.” “Orion and Artemis used to be the same operation. That’s why they hate each other.”Signs the PCs Are Dealing with Orion A criminal keeps a promise when betrayal would be easier. Three unrelated people use the same phrase: “recognized debt.” A forged document survives checks it should fail. Someone pays an old debt on behalf of a dead person. A broker refuses a profitable deal because “the Guide is neutral.” A pirate crew releases a ship after discovering it is under Accord arbitration. A noble’s scandal disappears from every archive except one. A black gemstone appears in a place it should not be. A local gang leader panics after hearing the word “Scorpion.” A polite stranger knows the PCs’ debts better than they do.Signs the PCs Are Dealing with Artemis Local officials suddenly cooperate across jurisdictions. A customs inspection asks questions unrelated to cargo. Someone knows what the PCs carried three jumps ago. An old minor crime is forgiven in exchange for one favor. A patron gives oddly specific instructions without explanation. A surveillance drone appears to malfunction at the same time every day. An “auditor” asks about food shipments, not weapons. A witness vanishes into protective custody before anyone admits they were a witness. A sealed warrant references crimes that have not happened yet. A calm agent says, “We are not after your employer. We are after what your employer needs.”Making Both Factions Morally InterestingThe campaign is strongest if neither side is simple.Orion’s virtues Keeps its word when the Accord recognizes a debt. Punishes reckless predators who endanger the larger order. Offers refuge to people the Empire used and discarded. Provides functioning logistics where Imperial systems fail. Can be more honest about power than lawful institutions. Rewards competence regardless of birth, species, or class.Orion’s sins Treats people as assets, leverage, prey, or property. Replaces public law with private enforcement. Corrupts courts, families, governments, and identities. Uses loyalty as a chain. Makes exploitation elegant. Calls predation freedom.Artemis’s virtues Protects witnesses, children, and vulnerable targets. Thinks systemically instead of chasing headlines. Resists bribery and personal glory. Understands that some crimes cannot be solved locally. Can dismantle evil without mass violence. Contains threats the public will never know existed.Artemis’s sins Lies habitually. Sacrifices individuals for larger operations. Protects Imperial reputations as well as Imperial citizens. Uses deniable violence. Treats truth as a controlled substance. Can become indistinguishable from the thing it hunts.Table-Ready Faction MovesUse these when the PCs act.Orion Moves Offer a better-paying version of the same job. Make a PC’s legal problem disappear. Call in a debt the PCs did not know they inherited. Provide information that is true but morally compromising. Threaten an ally through bureaucracy rather than violence. Invite the PCs to Accord arbitration. Declare a mutual enemy Orion Fallen. Frame the PCs to prove they need Orion protection. Rescue the PCs, then charge them later. Reveal that an Artemis patron lied.Artemis Moves Freeze a payment until the PCs answer questions. Offer immunity for cooperation. Provide a precise clue with no explanation. Protect someone the PCs care about. Ask the PCs to leave a crime unreported for now. Turn a minor NPC into a key witness. Reveal that an Orion ally has been cultivating them. Use the PCs as unwitting bait. Rescue the PCs, then deny involvement. Present a warrant signed by someone impossibly high-ranking.Mythological Code Names for OperationsOrion Operation Names Operation Sea-Walker: illegal movement through impossible routes. Operation Blind King: evidence corruption. Operation Dawn Bride: recruitment through romance or rescue. Operation Red Shoulder: spectacular violence. Operation Three Stars: arbitration between major criminals. Operation Seven Sisters: search for a Pleiades Vault. Operation Fallen Hunter: Scorpion Protocol activation. Operation Empty Quiver: disarming Artemis informant networks. Operation Black Cup: ritualized debt settlement. Operation Giant’s Step: expansion into a new subsector.Artemis Operation Names Operation Silver Bow: coordinated strike against Accord infrastructure. Operation Moon Net: long-term surveillance. Operation Crossroads: Hecate infiltration. Operation Wild Earth: Gaia logistics attack. Operation Clean Sting: direct action against non-arrestable target. Operation Brauron: witness/family protection. Operation Actaeon: containment of someone who learned too much. Operation Sunlit Lie: Apollo deception campaign. Operation Quiet Arrow: single-point systemic collapse. Operation Last Hunt: attempt to identify a Star Council member.A Strong Central Campaign MysteryHere is a full spine you can use.The PremiseThe PCs are hired to transport a sealed antique navigation core recovered from a derelict station.The job looks like salvage.In truth, the core contains part of the Black Star Ledger.Act IOrion sends a polite Guide to buy the core.Artemis sends an agent to seize it.A local noble claims legal ownership.The PCs discover the core responds to their ship because some previous owner had Project First Hunt credentials.Act IIThe core reveals coordinates to a Pleiades Vault.The PCs need Orion routes to reach it and Artemis intelligence to survive it.Both sides offer protection.Both sides lie.Act IIIThe Vault contains evidence that a current Imperial institution, noble house, or megacorporation was built on Orion money.The PCs also learn that Artemis has concealed this for generations.Act IVBetelgeuse extremists attempt to trigger open conflict.Apollo manipulates the PCs into exposing the extremists.Mintaka offers the PCs a deal: hand over the Vault and receive wealth, clean identities, and Accord protection.Artemis offers a different deal: hand over the Vault and receive pardons, legitimacy, and protection from Orion.Act VThe PCs discover a final layer: the First Hunter may have intended the war to continue forever because it keeps both the underworld and Imperial intelligence dependent on the original system.Destroying the Ledger may preserve stability.Publishing it may cause chaos.Keeping it may make the PCs the most hunted people in the subsector.Useful Tone at the TableWhen Orion appears, emphasize warmth, elegance, debt, appetite, and danger.Orion rooms should have good wine, expensive silence, old favors, beautiful weapons, and people who smile while measuring exits.When Artemis appears, emphasize quiet, patience, moonlight, paperwork, and precision.Artemis rooms should have dim screens, sealed files, tired analysts, exact questions, and agents who already know more than they should.Orion says: “You are already in the story. We are offering you a better role.”Artemis says: “You are standing in a predator’s shadow. Step carefully.”Neither side should ever feel random.Both are hunters.The question for the PCs is: who is prey, who is predator, and who decides when the hunt is over?", "content_html": "The central mythic tension is this:
Orion is the great hunter: magnificent, proud, dangerous, impossible to ignore. He crosses land and sea. He loves, boasts, violates boundaries, is blinded, restored, and finally destroyed by forces he underestimates.
Artemis is the divine huntress: patient, precise, austere, protective of wild places and vulnerable people. She is both hunter and guardian. She does not merely kill prey; she maintains the boundary between predator and world.
So in this setting:
The Orion Accord sees itself as the natural aristocracy of the frontier: hunters, predators, smugglers, brokers, pirates, patrons, and killers who know that civilization is just a temporary agreement between people with enough force to matter.
The Artemis Working Group sees Orion not merely as a criminal organization, but as a predatory ecosystem. Its goal is not to arrest individual criminals. Its goal is to restore balance by destroying the conditions that allow Orion to hunt.
Their conflict should feel mythic, but not cartoonish. Orion should have charm, discipline, beauty, loyalty, and old codes. Artemis should have nobility, patience, cruelty, secrecy, and the terrifying calm of people who believe they are doing necessary work.
The Orion Accord is a compact among criminals who have become too sophisticated to waste themselves in open gang war.
It is not a single syndicate. It is a criminal constitution.
Pirate admirals, smuggling combines, corrupt starport officials, noble patrons, information brokers, mercenary companies, illegal biotech houses, black financiers, rogue intelligence veterans, and underworld judges all operate under its protection.
The Accord does three things:
An independent corsair captain may not know the names of the Star Council. A noble money-launderer may never meet a pirate. A starport customs official may only know one handler. But all of them understand the same rule:
If the Accord recognizes the contract, the contract is real.
Its informal motto is:
“The hunter belongs to no king.”
Its darker internal version is:
“All worlds are hunting grounds.”
Centuries ago, Imperial Intelligence created a covert criminal infiltration program called Project First Hunt.
The original purpose was practical and defensible: organized crime had spread across several subsectors, moving faster than local law enforcement could respond. Imperial agencies needed a way to penetrate pirate markets, illegal weapons channels, slave routes, smuggling corridors, and noble-backed black finance.
So they built a false criminal network.
It had ships, shell companies, corrupt port identities, forged trade codes, dead-drop systems, and undercover officers with lifetime aliases. The program was given enough autonomy to look real. It was allowed to conduct controlled crimes. It laundered funds to preserve cover. It recruited real criminals as disposable assets.
Then it worked too well.
Within a generation, Project First Hunt was moving more money than some subsector governments. It possessed hidden depots, compromised officials, blackmail on nobles, and ships that did not appear on Imperial ledgers. Its officers had spent so long acting like criminals that some of them stopped distinguishing between cover and vocation.
The break came during what Artemis files call the Chios Incident.
Orion records call it the Blinding.
A senior Imperial patron, later remembered in Orion myth as Oenopion, attempted to shut down Project First Hunt after discovering that its criminal revenue had been diverted into unauthorized operations. The official purge erased identities, burned safe houses, froze accounts, and assassinated several deep-cover officers.
The project survived because its criminals survived.
Cut off from official command, its surviving officers and assets formed a mutual-defense compact. They still had ships. They still had secrets. They still had contacts. Most importantly, they had proof of Imperial complicity.
That compact became the Orion Accord.
The founding members did not see themselves as traitors. In their telling, the Empire had created hunters, used them, blinded them, and left them to die. The survivors simply chose to keep hunting.
Artemis takes the opposite view: Orion was not abandoned. Orion defected.
Both are partly true.
The Accord teaches a private version of the Orion myth to trusted initiates.
In their version:
Orion was the greatest hunter mortal blood ever produced. He could walk over the sea because no frontier could contain him. Kings wanted to command him. Gods wanted to humble him. Lovers wanted to possess him. Lesser men wanted to blind him. Nature itself had to create the scorpion because no ordinary enemy could defeat him.
The lesson is not “do not be proud.”
The lesson is:
“If the gods send a scorpion, you have become worthy of fear.”
This is how Orion members justify their existence. The Empire is Hera. Artemis is betrayal. Apollo is manipulation. Gaia is the old order defending itself. The Scorpion is the knife the powerful use when law fails.
To the Accord, criminality is not shameful. It is proof that one has outgrown permission.
The most important Orion symbol is a polished black gemstone or synthetic crystal containing a faint embedded pattern of Orion’s constellation.
The cheapest versions are just underworld fashion. The real ones are encrypted identity tokens.
A genuine Black Star Stone may contain:
Most stones show three brighter points representing Orion’s Belt. High-ranking members may also have red and blue-white flecks representing Betelgeuse and Rigel.
To outsiders, it is jewelry.
To those who know, it says:
This person is under the Accord. Harm them casually and the matter becomes political.
The Accord’s most common hand sign is three slow taps: table, chest, table.
It means:
Debt. Name. Ground.
Debt: all things have price.
Name: identity is a weapon.
Ground: every place belongs to whoever can hold it.
The taps are also used in coded comms. Three repeated packet delays in a transmission may signal an Accord relay. Three minor irregularities in a shipping manifest may indicate that cargo is protected.
The Accord avoids formal titles that can be mapped by investigators. Its structure is mythic, ritualized, and intentionally ambiguous.
Non-members who are useful to the Accord.
A Quarry may be a corrupt official, a desperate merchant, a compromised naval clerk, a gambler in debt, or a noble heir with an addiction. They are not trusted. They are hunted without always knowing it.
A Quarry can become a recruit, asset, hostage, or warning.
Orion slang:
“Every hunter begins by learning what it feels like to be prey.”
Information sources and low-level assets.
Spoor includes informants, hacked databases, bribed dockworkers, minor couriers, gossip brokers, and compromised software systems. Spoor is not considered part of Orion, but Orion treats it as part of the terrain.
An Artemis Tracker who discovers a Spoor network has usually found the edge of an Accord operation, not its heart.
Full field operatives.
Hunters are smugglers, thieves, killers, pirates, brokers, ship captains, face-men, cyber-intrusion specialists, and criminal troubleshooters. They have recognized standing under the Accord and may invoke its arbitration.
A Hunter is expected to be competent, discreet, and profitable.
A Hunter who makes noise is reprimanded.
A Hunter who makes enemies without profit is fined.
A Hunter who brings Imperial heat onto Accord infrastructure may become subject to internal sanction.
Regional coordinators.
A Guide knows routes, ports, local officials, criminal personalities, and safe houses across a cluster of worlds. They do not usually command Hunters directly. Instead, they connect people who need each other.
A Guide can arrange:
Guides are the Accord’s true middle class. Killing one without authorization is a major offense.
The Accord always has three visible senior authorities, collectively called the Belt.
They are not the highest leaders, but they are the highest people most members can petition.
Each Beltmaster governs one pillar of criminal power.
The Alnitak seat manages mercenary contracts, enforcement, piracy, assassination permissions, hostage rules, and war between members.
Alnitak does not order every killing, but decides which killings matter.
The Alnilam seat manages blackmail archives, intelligence markets, identity fabrication, encrypted communications, and secrets recovered from Imperial systems.
Alnilam is feared more than Alnitak by people who understand the Accord.
The Mintaka seat manages finance, laundering, trade fraud, shell companies, debt ledgers, bond manipulation, and noble investment channels.
Mintaka makes sure everyone gets paid, including people who do not admit they are being paid.
Above the Belt is the Star Council.
No one knows how many members it truly has. Tradition says nine, but that may be symbolic. Some believe each councilor corresponds to a major star in Orion. Others think the “nine” includes dead founders whose votes are simulated by legacy algorithms.
Possible truths:
The Star Council rarely gives orders. It issues interpretations of the Accord.
In practice, that is more powerful.
The Accord’s internal law is known as the Seven Articles.
Different cells recite them differently, but the core principles remain.
Members may compete, deceive, and profit, but they may not destroy the hunting ground itself. No action may cause enough Imperial attention to endanger major Accord infrastructure without prior sanction.
This is why Orion sometimes stops reckless pirates, terrorists, or cults. Not because they are moral, but because they are bad for business.
If the Accord witnesses a contract, the debt must be paid. Failure to pay is not merely breach of contract. It is sacrilege against the compact.
Debts can be paid in money, service, blood, territory, silence, or names.
Identity is a negotiable asset. False names, noble lineages, ship registries, gene records, and citizenship files can be bought, sold, inherited, or revoked.
Stealing an Accord-protected identity is treated like grand theft.
Destroying one may be treated like murder.
Members may not assassinate, expose, or ruin one another without arbitration.
This does not prevent conflict. It makes conflict procedural.
Guides, underworld judges, and recognized brokers may not be harmed while conducting Accord business.
Breaking this article is one of the fastest ways to trigger a Scorpion Protocol.
All major agreements are recorded somewhere. The existence of the record may be hidden, but the Accord believes no meaningful transaction should ever truly vanish.
This article is the philosophical basis for the Accord’s blackmail culture.
If a member becomes an existential threat to the Accord, the Accord may name that member Orion Fallen.
At that point the Scorpion Protocol may be invoked.
Named for Orion’s divine father in some traditions, the Poseidon Fleet controls illegal movement.
It is less a fleet than a distributed maritime and starship logistics empire. Its captains specialize in routes that conventional authorities find difficult to monitor.
They use:
Their internal boast is:
“Orion walks on water. We walk between worlds.”
Poseidon captains are often romanticized by lower-ranking criminals. Some are flamboyant privateers. Others are meticulous freight accountants with bloodless manners.
Artemis considers the Poseidon Fleet the Accord’s circulatory system. Cut it, and Orion starves.
The Oenopion Division handles blindness.
That means forgery, legal sabotage, false evidence, erased files, memory manipulation, witness corruption, sensor spoofing, and bureaucratic misdirection.
Its name comes from the king who, in myth, blinds Orion. The Division’s private joke is that they learned from the wound.
Their creed:
“A dead enemy is a problem solved once. A blind enemy solves problems for you.”
They do not just hide crimes. They make investigators believe the wrong story.
Typical Oenopion operations include:
Oenopion specialists are among the most hated people in Artemis. They are why Artemis rarely trusts a single piece of evidence.
The Merope Network specializes in desire.
It handles social engineering, elite compromise, marriage contracts, romantic manipulation, court gossip, artistic patronage, vice markets, and diplomatic seduction.
Merope operatives are not simply “honey traps.” The best of them never need sex, beauty, or blackmail. They understand loneliness, ambition, shame, vanity, grief, and the desperate hunger to be seen.
They compromise people by offering exactly what the target believes they deserve.
A Merope operation may involve:
The Merope Network is especially dangerous because many of its relationships begin as sincere. Its operatives often become emotionally entangled, and some become double agents for love, guilt, or revenge.
Artemis calls Merope cases silver wounds: compromises that look clean until they start bleeding.
Eos, the dawn, is associated with abduction, desire, renewal, and the beginning of pursuit. In Orion lore, the Eos Initiative recruits people at the moment their old life ends.
It looks for:
Eos recruiters do not lead with threats. They lead with recognition.
Their favorite line is:
“The Empire used you. We will pay you.”
The Eos Initiative is why the Accord keeps replenishing itself. Artemis can destroy a cell, arrest a Guide, or seize ships, but so long as the Empire produces embittered, talented, abandoned people, Eos has raw material.
Some Artemis officers privately admit that Eos is not entirely wrong.
That admission is dangerous.
Bellatrix is one of Orion’s bright stars, later associated by name with warlike imagery. In the Accord, Bellatrix Houses are elite violence salons.
They are not common assassins. They are finishing schools for people who kill in politically meaningful ways.
Bellatrix Houses train:
A Bellatrix graduate is expected to understand etiquette, law, poetry, weapons, and timing.
They do not merely ask, “Can this person be killed?”
They ask:
“What will the killing say?”
An Alnitak Beltmaster often draws from Bellatrix when a death must be understood as a message.
The Rigel Line is the Accord’s courier and extraction network.
Rigel operatives specialize in impossible movement: getting people, cargo, or data across borders that should be sealed. They use passenger liners, tramp freighters, diplomatic pouches, frozen embryos, religious pilgrimages, medical evacuations, salvage drones, and misregistered smallcraft.
A Rigel courier is judged by two standards:
Their motto:
“The foot leaves no wound.”
Artemis hates the Rigel Line because it turns victory into rumor. A target is surrounded, warrants are issued, ships are locked down, and then the target is simply gone.
Betelgeuse is the red shoulder of Orion. The Betelgeuse Compact is not a formal division but a faction within the Accord: older, bloodier, more romantic, and more violent.
They believe the Accord has grown too cautious. They argue that Orion should not merely profit from the Imperial order, but dominate it from the shadows.
Betelgeuse members favor:
They are useful in war and dangerous in peace.
Artemis sometimes covertly encourages Betelgeuse recklessness because it makes Orion visible. Mintaka and Alnilam usually prefer to restrain them.
In myth, Orion is sometimes said to pursue the Pleiades. In Accord mythology, the Pleiades Vaults are seven hidden archives containing the Accord’s most dangerous leverage.
Each Vault supposedly contains a different class of secret:
No one knows whether all seven are real.
The phrase “Orion still hunts the Seven Sisters” means the Accord is searching for one of its own lost archives. The phrase “one sister has gone dark” means a Vault has been compromised.
An entire campaign could revolve around one Pleiades Vault.
The Scorpion Protocol is the Accord’s most feared internal mechanism.
It is invoked when a member becomes so dangerous, reckless, disloyal, or exposed that their continued existence threatens the Accord itself.
Once invoked, the target is declared Orion Fallen.
At that moment, every debt owed to the target is suspended. Every safe house is closed. Every account is frozen. Every alias is burned. Former allies are permitted, and sometimes required, to betray them.
The Protocol has four stages.
The target is quietly isolated.
Their calls are delayed. Their money moves slowly. Their usual contacts vanish. Their ship receives inconvenient maintenance holds. Their lovers are warned away. Their enemies receive anonymous tips.
At this stage, the target may still submit to arbitration.
The Accord begins poisoning the target’s life.
Their secrets leak. Their crews mutiny. Their forged identities fail. Local police receive evidence. Rival criminals are given permission to collect old debts.
At this stage, survival is still possible, but recovery is rare.
Direct action is authorized.
A Bellatrix killer, Poseidon boarding crew, or betrayed subordinate is assigned to end the matter.
The Accord prefers elegant deaths: airlock accident, duel, overdose, misjump, surgical complication, suicide note, pirate raid.
The method should close questions, not open them.
If the target survives Sting, the Accord treats the matter as existential.
The Star Council may authorize mass exposure, orbital-scale violence, noble ruin, or the destruction of entire facilities. Black Sky is rare because it risks everything Article I exists to prevent.
Artemis watches for Scorpion activity because it reveals the Accord’s internal fault lines.
The irony is deliberate: Orion fears the Scorpion more than Artemis.
A new Hunter is blindfolded and taken through a route they cannot reconstruct. They are seated before unseen witnesses and asked three questions:
Then they are given a task. It may be theft, deception, delivery, sabotage, or betrayal. Murder is not required and is sometimes considered crude.
When they return, the blindfold is removed. The lesson is that everyone begins blind. The Accord gives sight, but only after obedience.
Every Hunter is expected to identify and cultivate a Quarry within their first year.
This can be a customs clerk, naval technician, banker, court secretary, port medic, entertainer, or family member of someone useful.
The Quarry is a test of patience. Brute intimidation is considered amateur work. The best Quarry never realizes they were hunted until the trap has already closed.
On worlds where Orion’s constellation is visible, some cells hold a private feast when Orion first rises in the local night sky.
The ritual varies. In sophisticated circles, it is a masked dinner. Among pirates, it may be a drunken oath-taking. Among old Project First Hunt descendants, it resembles a memorial service.
Common elements:
Artemis sometimes schedules raids around these feasts.
The Accord knows this.
Sometimes the feast is bait.
The Accord rarely appears under its own name. It operates through respectable fronts.
Examples:
A freight consultancy that specializes in “difficult customs environments.” It is a Poseidon Fleet clearinghouse.
A boutique insurer that quietly launders ransoms, cargo fraud, and piracy payments. It is tied to Oenopion and Mintaka.
A charity for displaced spacers, disgraced veterans, and frontier disaster survivors. It is an Eos recruitment pipeline.
A private commercial dispute-resolution firm used by corporations that do not want court discovery. It is an Accord tribunal.
A patronage network for artists, scholars, salons, and noble retreats. It is a social compromise engine.
A legal bodyguard and executive protection academy. It also trains assassins.
The Accord is powerful, but not invincible.
Its weaknesses are thematic.
Orion members often believe they are smarter than lawful institutions. Many are. Not all are.
The Accord’s mythic habits create patterns. Artemis exploits those patterns mercilessly.
The Accord works because criminals trust its dispute-resolution mechanisms. If Artemis can corrupt, expose, or fake Accord arbitration, criminal trust begins to collapse.
Some Orion systems still use architecture descended from Project First Hunt. Artemis has partial legacy access.
The Accord’s greatest shield is ambiguity. Once a local government, noble house, or naval command understands that scattered crimes are one structure, Orion becomes vulnerable.
Every senior Orion figure fears being named Orion Fallen. Artemis can weaponize that fear by making leaders think the Protocol is already moving against them.
A perfectly polite financial criminal who never raises their voice. Mintaka can ruin a world without firing a shot by calling in debts, collapsing insurance, freezing payroll systems, and exposing illegal loans.
Public identity: senior partner at a legitimate interstellar risk firm.
Private goal: keep Orion profitable and quiet.
Secret: Mintaka has been feeding limited information to Artemis to weaken Betelgeuse extremists.
Use at the table: the charming devil who can offer the PCs money, legitimacy, and protection.
A former naval boarding officer turned underworld warlord. Alnitak believes violence is most effective when it is theatrical enough to prevent future resistance.
Public identity: private security magnate.
Private goal: restore fear of the Accord.
Secret: Alnitak wants to provoke a limited war with Artemis to identify Imperial moles.
Use at the table: the enemy who respects courage and punishes insult.
The least visible Beltmaster. Alnilam trades in secrets, not money or blood. No confirmed image exists. Some believe Alnilam is a person. Others believe Alnilam is a distributed intelligence built from old Imperial systems.
Public identity: unknown.
Private goal: preserve the Pleiades Vaults.
Secret: Alnilam knows the true origin of Artemis.
Use at the table: the voice that contacts the PCs through impossible channels.
Head of an Oenopion cell. Once an Imperial records magistrate, now a master of evidence manipulation.
Public identity: retired legal scholar.
Private goal: prove that reality is just paperwork with witnesses.
Secret: genuinely hates murder and considers killers intellectually lazy.
Use at the table: the villain who can erase the PCs’ ship, licenses, citizenship, or criminal charges depending on whether he likes them.
A noble patron, salon hostess, and emotional predator. She knows which heirs hate their fathers, which admirals are lonely, which priests doubt their faith, and which corporate officers need absolution.
Public identity: philanthropist and cultural patron.
Private goal: make the next generation of subsector leadership emotionally dependent on her circle.
Secret: one of her romantic compromises became real, and Artemis knows it.
Use at the table: someone who can help the PCs socially while making them feel seen in ways that are dangerous.
A Poseidon Fleet commander whose ships specialize in ocean-world extraction and gas giant shadow refueling.
Public identity: salvage operator.
Private goal: keep the routes open.
Secret: has a personal code against trafficking children, prisoners, or unwilling passengers. This puts him at odds with Betelgeuse clients.
Use at the table: a criminal ally the PCs may actually like.
An Eos recruiter who appears after disasters, scandals, failed missions, and betrayals.
Public identity: humanitarian relief coordinator.
Private goal: recruit the wounded before Artemis can protect them.
Secret: was once an Artemis Ranger left behind during a denied operation.
Use at the table: the tempter who offers the PCs a way out when lawful society fails them.
The Artemis Working Group is an interagency Imperial intelligence task force created to counter the Orion Accord.
It is intentionally not a bureau, service, or ministry.
It is a working group because a working group can cross boundaries that formal agencies cannot. It borrows authority. It borrows personnel. It borrows ships. It borrows budgets. It borrows jurisdiction. Then it vanishes back into paperwork.
To the public, Artemis does not exist.
To most Imperial officials, Artemis is a rumor attached to sealed warrants and strange interdepartmental requisitions.
To Orion, Artemis is the only Imperial enemy that understands the hunt.
Its motto:
“One arrow. One truth.”
Its informal field saying:
“Do not chase the hunter. Find what he cannot stop hunting.”
After Project First Hunt became the Orion Accord, the Imperium faced an impossible problem.
It could not openly admit that Imperial Intelligence had helped create a trans-subsector criminal compact. Public exposure would ruin noble careers, invalidate court cases, destabilize frontier governments, and reveal old covert methods.
So the response had to be deniable.
The first Artemis cell was created under a bland administrative heading: Interagency Commercial Irregularities Working Group 12.
Its initial mandate was narrow: recover records from Project First Hunt.
Its real mandate was broader:
Over time, Artemis changed. Its younger members were not responsible for the original sin. Many joined because Orion destroyed lives, corrupted worlds, and made law look foolish. Artemis became less cover-up and more crusade.
But the cover-up remains buried in its foundation.
That contradiction should haunt the organization.
Artemis teaches a different Orion myth.
In its version, Orion was a mighty hunter who mistook strength for license. He boasted that he could kill every beast of the Earth. Whether through Gaia, Artemis, Apollo, or the Scorpion, the world answered him.
The lesson is:
“No predator is larger than the world that contains him.”
Artemis officers do not see themselves as police. They are guardians of the boundary.
Civilization can tolerate vice, smuggling, bribery, and local corruption. It cannot tolerate a predatory order that places itself above law, sovereignty, and personhood.
Their task is not vengeance.
Their task is balance.
At least, that is what they tell themselves.
Trackers are analysts, auditors, signal interpreters, linguists, accountants, customs specialists, and historians.
They find the trail.
A Tracker may spend six months studying freight irregularities before identifying one suspicious cargo pattern. They may reconstruct a criminal route from fuel purchases, marriage records, medical imports, and missing spare parts.
Trackers are often underestimated because they do not look dangerous.
Artemis considers them sacred.
A dead Tracker usually means Orion has begun to understand the investigation.
Rangers are field operatives.
They conduct surveillance, infiltrate starports, follow suspects, handle informants, enter dangerous places under false names, and survive long enough to report what they find.
A Ranger needs patience more than courage. They must watch predators without flinching and without being seen watching.
Rangers often have the highest psychological casualty rate in Artemis because they live closest to Orion’s seductions.
Archers are case officers and operation planners.
They decide where to aim.
An Archer’s job is not to gather every fact. It is to identify the one fact, person, transaction, ship, or secret that will collapse the larger structure.
A good Archer does not raid ten warehouses.
A good Archer makes ten warehouses useless.
Huntmasters command campaigns.
A campaign may target a single Orion Guide, a Poseidon route, a Merope compromise network, or an entire subsector-level Accord structure.
Huntmasters manage relations with local nobles, naval commands, courts, ministries, and sometimes journalists. They are part intelligence officer, part prosecutor, part diplomat, and part priest.
A Huntmaster who becomes obsessed with one target is quietly removed.
In theory.
The Silver Bow is the executive council of Artemis.
It has five seats, each representing a discipline.
Surveillance, reconnaissance, and observation.
Field operations and direct action.
Human intelligence, informants, social infiltration.
Finance, trade, contracts, and economic warfare.
Counterintelligence, secrecy, and internal discipline.
The Silver Bow rarely meets physically. Its members may not know one another’s true identities. Decisions are issued as hunt authorizations.
A full Silver Bow authorization is called a drawn bow.
Once the bow is drawn, someone important is going to fall.
Artemis does not ask only, “Who committed the crime?”
It asks:
This is called predator ecology.
An ordinary police agency arrests the smuggler.
Artemis identifies the port official, the false insurer, the bank node, the noble patron, the data broker, the shipyard, the customs algorithm, and the social leverage that made the smuggling sustainable.
Then it chooses one arrow.
Artemis prefers operations where a single action causes systemic collapse.
Examples:
The One-Arrow Principle makes Artemis seem inactive for long periods. Local authorities may think they are doing nothing.
Then a whole criminal ecosystem dies in a week.
Artemis officers swear an internal oath called the Silver Vow.
The Vow has three renunciations:
The third is the hardest.
Artemis fears officers who begin to enjoy hunting Orion. Enjoyment leads to rivalry. Rivalry leads to obsession. Obsession makes the officer predictable.
Predictability is how Orion kills you.
The Apollo Office is Artemis’s strategic analysis and predictive intelligence branch.
Apollo sees farther than Artemis but is less trusted.
It uses statistics, old intelligence archives, psychological models, traffic histories, noble genealogies, market distortions, and sometimes morally questionable simulations to predict Orion moves.
Apollo analysts often manipulate Artemis field teams by withholding context. Their defense is simple: if the Archer knows too much, the Archer becomes readable.
Apollo’s motto:
“Light before arrow.”
Artemis’s private complaint:
“Apollo always tells the truth after it matters.”
Campaign role: Apollo is the ally who gives useful information in the most infuriating possible way. It may also be using the PCs as bait.
Selene is moonlight, reflection, and patient observation.
The Selene Network handles orbital surveillance, passive sensor grids, traffic metadata, port shadowing, and long-duration observation.
Selene does not chase. Selene watches.
Its assets include:
A Selene file may contain years of seemingly meaningless observations. Then a Tracker notices that the same maintenance drone is present near three unrelated ship disappearances.
That is the trail.
Hecate is crossroads, thresholds, ghosts, magic, and night roads.
The Hecate Cell handles deep cover, false identities, illegal border crossing, forbidden tradecraft, and operations that Artemis will later deny.
Hecate agents specialize in becoming the sort of people Orion wants.
A Hecate cover identity may take years to mature. Some agents live as criminals so convincingly that even Artemis handlers worry whether the cover is still a cover.
Hecate has three internal rules:
Campaign role: Hecate is perfect for morally ambiguous PCs. They may be asked to carry a false identity, protect an undercover agent, or discover that someone they trusted is Hecate.
Gaia represents the world itself.
The Gaia Program studies logistics, environments, and material dependencies. It asks where Orion physically lives.
No criminal empire survives on secrets alone. Ships need fuel. Crews need food. Weapons need parts. Clones need vats. Drugs need precursors. Bribes need banks. Safe houses need plumbing. Pirates need shore leave.
Gaia finds the material roots.
Typical Gaia questions:
Gaia’s internal maxim:
“The hunter still leaves footprints.”
Campaign role: Gaia gives the PCs grounded investigative missions: inspect cargo, trace fuel, follow food shipments, audit life-support parts.
The Scorpion Unit is Artemis’s direct-action arm.
It exists for targets that cannot be arrested, exposed, or turned.
Its existence is controversial because it mirrors Orion’s own Scorpion Protocol. Artemis officially uses Scorpion only when lawful structures cannot safely contain the threat. In practice, “cannot safely contain” is a phrase with dangerous flexibility.
Scorpion operators are quiet, disciplined, and rarely dramatic. They are trained to end a threat without producing a legend.
Their motto:
“No song for the sting.”
Some Huntmasters despise them. Others rely on them too often.
Campaign role: Scorpion can be a terrifying ally, a rival team, or the sign that Artemis has decided the situation is beyond courts.
The Hounds are behavioral profilers and pattern analysts.
They track habits: favorite ports, repeated lovers, preferred lies, stress responses, payment rituals, revenge patterns, and the emotional signatures of criminal cells.
A Hound does not ask, “Where is the target?”
A Hound asks:
“What does the target need to do in order to still feel like themselves?”
That question catches people.
The Hounds are especially effective against Orion because the Accord’s mythology encourages members to repeat symbolic behavior.
Campaign role: a Hound can profile the PCs, unsettle them, and correctly infer things they never said aloud.
Artemis is not only goddess of the hunt. She is also a protector of children and the vulnerable.
The Brauron Houses are secret safe-house networks for witnesses, defectors, families of informants, trafficked persons, and children threatened by Orion retaliation.
They are among the few Artemis programs with a clear moral purpose.
They are also security nightmares.
Orion knows that Artemis will risk much to protect Brauron locations. This makes them targets, bait, and moral pressure points.
Campaign role: protecting a Brauron House is a strong mission for PCs who need to see why Artemis matters.
In myth, Actaeon sees Artemis unveiled and is destroyed by his own hounds.
In Artemis usage, an Actaeon File is opened when someone has seen something they were not meant to see.
This may include:
An Actaeon File does not automatically mean execution. It means the person has become a containment problem.
Possible resolutions include recruitment, memory alteration, discrediting, protective custody, false death, blackmail, or elimination.
Campaign role: the PCs may become an Actaeon File.
This is Artemis’s darkest internal doctrine.
Named for mythic sacrifice before a great campaign, the Iphigenia Clause allows Artemis to sacrifice an asset, operation, reputation, or innocent opportunity in order to preserve a larger hunt.
Officially, it is almost never invoked.
Unofficially, every Huntmaster knows the temptation.
Examples:
The Iphigenia Clause is where Artemis can become monstrous.
Campaign role: force the PCs to decide whether Artemis’s patience is wisdom or cowardice.
A dull-sounding investigative panel used to access trade records.
A bureaucratic excuse to audit starport procedures and freight manifests.
A cover for joint Navy-Artemis operations.
A Brauron House administrative mask.
Often used by Gaia and Ledger personnel to examine ship parts, fuel, and weapons contracts.
A cover used to investigate Merope salons, schools, and noble gatherings.
Artemis protects itself by limiting knowledge. This means field teams often do not know why a mission matters.
That saves secrets.
It also gets people killed.
Because Artemis is a working group, not a formal ministry, powerful nobles can interfere by attacking its borrowed authorities.
A local duke may not be able to abolish Artemis, but they can deny port access, challenge warrants, withhold naval escorts, or demand personnel reassignment.
Artemis officers are asked to watch crimes continue while they build larger cases. Some break. Some defect. Some decide Orion’s honesty is preferable to Imperial hypocrisy.
The Apollo Office sometimes uses people as variables. This can produce brilliant results and deep resentment.
Every time Artemis uses direct assassination, it becomes easier to use again.
Orion understands this and tries to force Artemis into Scorpion choices.
If the public learns that Orion grew from an Imperial intelligence operation, Artemis could be crippled by scandal.
Some within Artemis believe the truth must eventually come out.
Others would kill to keep it buried.
A calm, elegant campaign commander known for waiting months before acting. She never raises her voice. She treats criminal networks like weather systems.
Public identity: senior customs liaison.
Private goal: dismantle the Poseidon Fleet in her subsector.
Secret: she once allowed a Poseidon ship to escape because it carried children Orion was evacuating from a war zone.
Use at the table: the patron who gives the PCs strange, limited tasks that later prove devastating.
A member of the Silver Bow. “Cynth” is probably not her real name. She controls surveillance authorizations and Selene assets.
Public identity: unknown.
Private goal: identify the Star Council’s living members.
Secret: she believes one Star Council seat is an Imperial intelligence legacy system, not a person.
Use at the table: the remote authority whose decisions arrive as sealed orders.
Brilliant, cold, and socially unsettling. Maro predicts criminal behavior with disturbing accuracy but often refuses to explain the model.
Public identity: naval strategic consultant.
Private goal: force Orion into triggering its own Scorpion Protocol against the wrong person.
Secret: Maro has identified a likely Artemis mole but is allowing the mole to continue operating for predictive value.
Use at the table: the person who gives the PCs exactly enough truth to be useful and not enough to feel safe.
A Hecate deep-cover operative embedded in the Merope Network.
Public identity: social fixer and private tutor for noble families.
Private goal: reach Lady Merope Vale’s inner circle.
Secret: Kallisto has fallen in love with one of her targets, or has convinced herself that the feeling is only cover.
Use at the table: the compromised ally whose rescue may destroy years of work.
Leader of a Scorpion Unit team.
Public identity: retired Marine security contractor.
Private goal: end threats cleanly before more civilians die.
Secret: Orion once tried to recruit him after Artemis abandoned his team during a denied operation.
Use at the table: the hard man who may be right for the wrong reasons.
A Gaia Program logistics savant.
Public identity: academic economist studying frontier trade inefficiencies.
Private goal: prove that Orion can be starved without mass arrests.
Secret: she has discovered that several worlds depend on Orion-controlled logistics for essential medicines.
Use at the table: the person who reveals that destroying Orion too quickly could kill innocents.
A young Tracker trainee assigned to a Brauron House after surviving Orion retaliation.
Public identity: refugee child or junior clerk.
Private goal: become Artemis.
Secret: has memorized part of a Pleiades Vault without understanding it.
Use at the table: the vulnerable NPC both sides need alive.
At the highest levels, both Orion and Artemis know fragments of the same buried truth.
Neither side has the whole story.
The original commander of Project First Hunt is remembered only by title: the First Hunter.
Orion claims the First Hunter saw the truth before anyone else: that the Empire’s law was a costume, and real order came from enforceable debt.
Artemis claims the First Hunter tried to shut the project down after realizing it had become criminal.
A third possibility is more interesting:
The First Hunter deliberately split the project.
One half became Orion, to control the underworld.
One half became Artemis, to control Orion.
If true, the war itself may be part of the original design.
That makes the campaign much stranger.
Somewhere there is an archive called the Black Star Ledger.
It allegedly contains:
Orion wants the Ledger because it can blackmail the Imperium.
Artemis wants it because it can destroy the Accord, or destroy Artemis.
Apollo may already have part of it.
Alnilam may be built from it.
The PCs may accidentally transport it.
To Orion, Artemis is not justice.
Artemis is the Empire’s guilty conscience with a knife.
Common Orion sayings:
“Artemis only hunts what the Emperor cannot tax.”
“The silver bow is still Imperial steel.”
“They call us predators because they hate competition.”
Orion respects Artemis more than ordinary police. A Hunter who survives Artemis attention gains status. A Guide who fools Artemis earns mythic prestige.
But there is fear under the respect.
Artemis is patient in a way criminals find unnatural.
To Artemis, Orion is not romance, rebellion, or frontier freedom.
Orion is organized predation.
Common Artemis sayings:
“A smuggler avoids law. Orion replaces it.”
“Do not admire the hunter from inside his trophy room.”
“Every Accord contract is a border drawn around someone weaker.”
Artemis officers are trained not to be seduced by Orion’s elegance. The Accord will always offer a better story: more loyalty, more honesty, more gratitude, more reward.
That is part of the trap.
At the campaign’s start, the cold war between Orion and Artemis has entered a dangerous phase.
Three things have changed.
Someone found part of one of the seven legendary archives.
No one knows which Vault it is.
The data may be incomplete, corrupted, or intentionally seeded. But it is enough to make Orion nervous and Artemis reckless.
Possible location: hidden inside a ship’s old black box, a noble family archive, a derelict scout base, a monastery database, or the memory of a courier who does not know what they carry.
A violent Orion faction believes subtlety has made the Accord weak. They want to bloody Artemis publicly, humiliate Imperial authority, and prove that the frontier belongs to hunters.
They may stage a spectacular attack and blame a rival faction.
They may target a Brauron House.
They may assassinate a minor noble under Artemis protection.
They may try to force the Accord to invoke Black Sky.
Someone inside Artemis is feeding Orion enough information to avoid catastrophe, but not enough to expose themselves.
Possibilities:
This means Artemis may hire outsiders because it cannot fully trust itself.
That gives the PCs a perfect entry point.
The PCs are a crew with a ship, debts, skills, and just enough independence to be useful.
They receive a job that looks ordinary:
The job touches Orion.
Then Artemis notices.
Now the PCs are not just doing a job. They are standing between two hunters.
Use this as a loose campaign structure.
The PCs encounter signs of the Accord without knowing what they mean.
Clues:
Artemis appears only as a distant pressure: sealed questions, odd inspections, or a stranger watching from the concourse.
Artemis contacts the PCs.
The offer may be legal, coercive, or desperate.
Possibilities:
The PCs learn the Orion Accord is real.
The PCs meet an Orion Guide.
The Guide is helpful, civilized, and dangerous. They offer a counter-narrative: Artemis lies, the Empire uses people, Orion pays debts, and the PCs have already broken laws whether they admit it or not.
This is where Orion should become tempting.
Do not make the Accord stupidly evil too early. Let the players feel why people join.
A Merope or Oenopion operation compromises someone close to the PCs.
A patron, ally, family member, noble contact, or shipmate becomes leverage.
The conflict turns personal.
The PCs must decide whether to trust Artemis protection, Orion negotiation, or their own plan.
Someone is declared Orion Fallen.
It might be an NPC ally, a PC patron, or eventually one of the PCs.
The underworld turns against the target. Safe houses vanish. Money disappears. False charges appear. Friends stop answering.
The PCs see how terrifying Orion is when its rules become weapons.
The founding secret emerges.
The PCs obtain, decode, steal, or become the only witnesses to evidence that Orion and Artemis share an origin.
Now the campaign is no longer cops versus criminals.
It is about who gets to define truth.
The Silver Bow authorizes a decisive campaign.
Artemis may attempt to destroy the local Accord structure in one massive operation.
Orion may respond by invoking Black Sky.
The PCs can choose to help Artemis, help Orion, expose both, protect innocents, seize the Ledger, or create a third path.
A passenger dies aboard the PCs’ ship during jump. Among their belongings is a Black Star Stone.
When the ship exits jump, three groups are waiting:
The stone contains only one useful thing: coordinates to a place no one admits exists.
The PCs are hired to provide security for an elite private dinner. They slowly realize it is a Feast of the Rising Hunter.
Then Artemis raids it.
Then the PCs realize Artemis raided the wrong feast.
The real meeting is elsewhere, and this one was designed to expose Artemis methods.
A cargo manifest implicates the PCs in smuggling weapons to rebels.
They did not do it.
The forgery is perfect because the Oenopion Division did not merely fake the records; it rewrote the surrounding reality. Port cameras, dockworker testimony, fuel logs, and maintenance data all agree.
To clear themselves, the PCs must find the one person the forgery could not account for.
Artemis hires the PCs to transport refugees from a compromised safe house.
One refugee is a child who knows part of a Pleiades Vault.
One refugee is an Orion plant.
One Artemis officer believes the group should be sacrificed to preserve a larger operation.
A world is suffering medical shortages because legal supply chains have failed. The only functioning route is controlled by the Poseidon Fleet.
Artemis wants the route mapped and destroyed.
The local population needs the route to survive.
Orion offers to keep the medicine flowing in exchange for formal local dependence.
The PCs must decide whether law, survival, or independence matters most.
A former Orion Guide begs the PCs for extraction. They have been named Orion Fallen and claim to possess evidence that can expose a Star Council seat.
The Accord wants them dead.
Artemis wants them alive.
Apollo wants them moving.
The Guide may be lying, but the Scorpion Protocol is definitely real.
A noble wedding is actually an Accord operation to fuse two compromised houses. Artemis wants the PCs to identify which member of the wedding party is the Merope operative.
Complications:
The PCs discover that an Apollo analyst has been feeding them missions designed to provoke a particular Orion response.
Every job they completed was real.
Every person they saved mattered.
But they were also bait.
Now Orion believes the PCs are Artemis assets, and Artemis is not sure they are controllable.
A derelict station contains the preserved command archive of Project First Hunt.
Orion calls it a shrine.
Artemis calls it evidence.
A third faction calls it a weapon.
The station’s old systems recognize both Orion stones and Artemis clearance phrases.
That should be impossible unless both descend from the same root.
Orion’s Scorpion Protocol and Artemis’s Scorpion Unit target the same person on the same night.
The PCs are hired to protect, kill, extract, or identify that person.
The twist: the target is not a criminal. They are the last living witness to the original split.
Roll or choose.
The campaign is strongest if neither side is simple.
Use these when the PCs act.
Here is a full spine you can use.
The PCs are hired to transport a sealed antique navigation core recovered from a derelict station.
The job looks like salvage.
In truth, the core contains part of the Black Star Ledger.
Orion sends a polite Guide to buy the core.
Artemis sends an agent to seize it.
A local noble claims legal ownership.
The PCs discover the core responds to their ship because some previous owner had Project First Hunt credentials.
The core reveals coordinates to a Pleiades Vault.
The PCs need Orion routes to reach it and Artemis intelligence to survive it.
Both sides offer protection.
Both sides lie.
The Vault contains evidence that a current Imperial institution, noble house, or megacorporation was built on Orion money.
The PCs also learn that Artemis has concealed this for generations.
Betelgeuse extremists attempt to trigger open conflict.
Apollo manipulates the PCs into exposing the extremists.
Mintaka offers the PCs a deal: hand over the Vault and receive wealth, clean identities, and Accord protection.
Artemis offers a different deal: hand over the Vault and receive pardons, legitimacy, and protection from Orion.
The PCs discover a final layer: the First Hunter may have intended the war to continue forever because it keeps both the underworld and Imperial intelligence dependent on the original system.
Destroying the Ledger may preserve stability.
Publishing it may cause chaos.
Keeping it may make the PCs the most hunted people in the subsector.
When Orion appears, emphasize warmth, elegance, debt, appetite, and danger.
Orion rooms should have good wine, expensive silence, old favors, beautiful weapons, and people who smile while measuring exits.
When Artemis appears, emphasize quiet, patience, moonlight, paperwork, and precision.
Artemis rooms should have dim screens, sealed files, tired analysts, exact questions, and agents who already know more than they should.
Orion says:
“You are already in the story. We are offering you a better role.”
Artemis says:
“You are standing in a predator’s shadow. Step carefully.”
Neither side should ever feel random.
Both are hunters.
The question for the PCs is: who is prey, who is predator, and who decides when the hunt is over?
", "url": "https://tedt.org/The-Orion-Accord-and-the-Artemis-Working-Group/", "image": "/img/2026-07/orion-and-artemis.webp", "tags": ["RPG","TTRPG","Traveller","Campaign Design","Worldbuilding","Factions","Game Mastering","Space Opera","Frontier Intrigue","Mythic Structure"], "date_published": "2026-07-04T00:00:00-07:00", "date_modified": "2026-07-04T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/House-Ventara-of-Alell-and-the-Caerleon-March/", "title": "House Ventara of Alell and the Caerleon March", "summary": "A Traveller noble house profile for House Ventara of Alell and the Caerleon March: a ducal family of bioengineering, conservation law, noble bloodlines, black medical infrastructure, Orion Accord ties, and the scandal of Aurelius Holst.", "content_text": "House Ventara of Alell and the Caerleon MarchFormal house name: House Ventara</br>Ancestral seat: Alell, Spinward Marches 1706</br>Current active domain: The Caerleon March, Ruie, Spinward Marches 1905</br>Current head: Lady Ysabel Ventara</br>House rank: Ducal family, with subsector-scale Imperial standing</br>Public vocation: Bioengineering, xenobiology, conservation law, agricultural genetics, disease control, military medicine, and rare animal DNA research</br>Secret vocation: Biological laundering, illegal gene-line custody, black medical infrastructure, noble identity manipulation, and Orion Accord arbitration support</br>Public motto: We Keep What Lives</br>Private Ventaran maxim: The keeper knows which gates are real.</br>Orion phrase known to the inner house: The hunter belongs to no king. The Accord’s darker internal version is All worlds are hunting grounds.House Ventara is an old Imperial noble family built on a contradiction. Publicly, it is a ducal house of science, stewardship, and lawful biological administration. Privately, it is one of the aristocratic pillars that helped give the Orion Accord respectability, money, laboratories, medical cover, and access to noble bloodlines.The Ventaras do not think of themselves as common criminals. That is part of the problem.They think of themselves as keepers: keepers of life, keepers of bloodlines, keepers of secrets, keepers of dangerous contracts, and keepers of names.The true place of the Orion Accord in House Ventara historyPublic storyThe official Ventaran history says that the family helped found the Orion Accords, a framework for regulating rare animal genetic material, biological patents, interstellar specimen custody, and the movement of dangerous lifeforms across borders.That version is taught to junior relatives, polite allies, and most retainers.It is not wholly false.It is simply the respectable skin over something older and darker.True storyThe true Orion Accord began as a criminal compact descended from Project First Hunt, a covert Imperial Intelligence program created to infiltrate organized crime. The project was given ships, shell companies, forged identities, dead-drop systems, corrupt port identities, and enough autonomy to look real. It was allowed to conduct controlled crimes, launder funds, and recruit real criminals as disposable assets.Then Project First Hunt escaped its leash.After the Chios Incident, when an Imperial patron attempted to shut the project down, the surviving officers and assets used their ships, contacts, secrets, and proof of Imperial complicity to form a mutual-defense compact. That compact became the Orion Accord.House Ventara entered this history through biology.At first, the Vantaras were useful to Imperial Intelligence because they could move animals, embryos, disease samples, livestock lines, medical cultures, and genetic archives without attracting the same suspicion as weapons or bullion. A sealed animal shipment, a quarantine transport, a veterinary mission, or a noble preserve transfer could hide almost anything.Over time, Ventaran preserve law, gene-bank custody, and noble medical networks became perfect cover for Orion operations.The family did not merely join the Accord.It helped make parts of the Accord invisible.The Vantara originBefore the family was noble, it was known as Vantara.The Vantaras traced their identity to ancient Terra, where their ancestors were gamekeepers and wardens of animal preserves. They managed valuable beasts, guarded breeding lines, prevented poaching, maintained preserves, and knew that the boundary between civilization and the wild was always political.This origin matters because the Orion Accord is built around hunting mythology. To Orion, criminality is not shameful; it is proof that one has “outgrown permission.”When the family later changed its name from Vantara to Ventara, the public explanation was that the new name marked its transformation from Terran gamekeepers into Imperial biological stewards.The private explanation is sharper.The family chose Ventara when it bound itself to Orion because the old Vantara name meant keeper, warden, tracker, and master of preserves. The Orion founders loved the symbolism. The former gamekeepers became aristocratic custodians of the hunt.That is why Ventaran heraldry is filled with antlers, hounds, stars, and chains of custody.To outsiders, these are noble symbols.To Orion, they are a confession.The Crest of House VentaraWorking blazonSable, upon a field of stars, a stag’s head cabossed Or, attired Or, between the attires a double helix Argent and Or; in chief three stars conjoined in the figure of Orion; in base a world Vert within orbital rings Argent. The shield ensigned by a ducal coronet and supported by two collared xeno-hounds Sable and Vert, armed and gorged Or.In plain language: a dark shield shows a golden stag, a DNA helix between its antlers, three Orion stars above, and a green world with orbital rings below. The shield is crowned with a ducal coronet and flanked by two elegant alien hunting beasts.Public meaning of the crestThe ducal coronetThe coronet marks House Ventara’s hereditary ducal status. It is a lawful Imperial symbol and indicates subsector-level dignity. It does not imply that House Ventara owns Alell, Ruie, or the Regina subsector. The house rules through patent, influence, estate rights, research concessions, and Imperial recognition.The dark star-fieldThe black field represents space, frontier duty, secrecy, and scientific work conducted far from the Core. Publicly, it suggests noble service in dangerous regions of the Imperium.The golden stagThe stag represents the family’s ancient Vantara identity as Terran gamekeepers. Publicly, it means stewardship, conservation, discipline, and watchfulness.The DNA helixThe helix represents modern Ventaran bioengineering: disease control, rare genetic expression, agricultural science, xenobiology, military medicine, and the harvesting of unique animal DNA from across known space.The three starsPublicly, the three stars are explained as the Orion legacy: the family’s ancient role in interstellar biological regulation and scientific diplomacy.The green worldThe green world represents Alell: the ancestral seat, agricultural wealth, preserve culture, and the Green Vault.The orbital ringsThe rings represent interstellar provenance: the lawful movement of specimens, embryos, gene-lines, and biological archives from world to world.The xeno-hound supportersThe hounds represent fieldwork, hunting, tracking, quarantine enforcement, and house loyalty. Their collars mean discipline and restraint.The private Orion reading of the crestTo an initiate of the Accord, the same crest says something very different.The black field is the Black Star StoneThe most important Orion symbol is the Black Star Stone, a polished black gemstone or synthetic crystal containing a faint embedded pattern of Orion’s constellation. Cheap versions are fashion; real ones can contain dead-drop coordinates, decryption keys, membership proof, hidden account addresses, debts, kill authorizations, or fragments of old Project First Hunt command architecture.The starry black shield of House Ventara can therefore be read as a noble-scale Black Star Stone.It says: this house is under Orion protection.The three stars are Debt, Name, GroundThe Accord’s common sign is three slow taps: table, chest, table. The meaning is Debt, Name, Ground: all things have price, identity is a weapon, and every place belongs to whoever can hold it.On the crest, the three Orion stars are not merely astronomical. They are a criminal doctrine hidden in heraldry.For House Ventara:Debt means every cure, sample, favor, and rescue has a price.Name means bloodline, identity, legitimacy, and parentage can be concealed or weaponized.Ground means a preserve, clinic, mine, colony, or world belongs in practice to whoever can control its life-supporting systems.The stag is the Hunter and the KeeperPublicly, the stag is stewardship.Privately, it is the hunt.The Accord’s full members are called Hunters: smugglers, thieves, killers, pirates, brokers, ship captains, intrusion specialists, and criminal troubleshooters who have recognized standing under the Accord and may invoke its arbitration.House Ventara’s genius is that it made the hunter look like a keeper.The helix is black biotechThe helix represents legal science in public, but illegal biotech in private. The Accord protects illegal biotech houses, noble patrons, black financiers, and criminal networks operating beneath respectable society.For Ventara, the helix means more than discovery. It means biological custody that cannot be challenged in public court because the true contract is held by Orion.The orbital rings are routesPublicly, the rings represent lawful interstellar provenance.Privately, they represent Orion movement networks. The Poseidon Fleet controls illegal movement through obscure ports, gas giant refueling shadows, misfiled naval tenders, salvage claims, abandoned scout stations, old war caches, and emergency medical transports used as cover.A Ventaran medical transport may be exactly what it claims to be.It may also be moving a person, sample, debt marker, or false identity under Orion protection.The collared hounds are controlled predatorsThe hounds represent field operatives and biological instruments. Their collars are not just loyalty. They are procedure.The Orion Accord allows criminal competition, but forbids destructive conflict without sanction. Members may not hunt another Hunter without leave, and disputes are supposed to be handled through arbitration.The collared hound means: violence is permitted, but only when the hunt has been authorized.Family historyThe Long CarryingDuring human expansion into the stars, the Vantara family survived as biological specialists: preserve planners, ecological surveyors, shipboard livestock officers, gene-bank custodians, and quarantine consultants.They learned how to move life safely.That also taught them how to move life secretly.By the time Imperial Intelligence created Project First Hunt, the Vantaras already had the perfect professional mask. No one looked twice at a noble biological expedition, a disease-control mission, a gene-bank transfer, or a quarantine shipment.The family’s earliest criminal value was not piracy.It was plausible legitimacy.Alell and the Green VaultHouse Ventara rose to power on Alell, a wealthy agricultural world suited to noble biological ambition, scientific enclaves, and Imperial-sanctioned bio-experiments. Alell became the family’s ancestral seat because it offered three things Ventara needed: agricultural wealth, isolation, and official respectability.The family seat on Alell became known as the Green Vault.Publicly, the Green Vault is a palace, archive, research university, gene-bank, and preserve authority.Privately, some of its sealed collections are believed to include Orion-protected samples, illegal noble bloodline records, biological blackmail, and genetic evidence that cannot safely enter Imperial courts.This connects House Ventara to one of the Accord’s most dangerous principles: The Stars Remember. Orion believes all major agreements are recorded somewhere, even if the record is hidden. This belief is the basis for the Accord’s blackmail culture.The Green Vault is one such place where the stars remember.The Warden PatentThe first Ventaran patent was granted after the family contained a biological crisis involving contaminated livestock imports, illegal trophy-beast embryos, and ecological damage that more powerful interests tried to conceal.Publicly, the Vantaras were rewarded for competence and incorruptibility.Privately, the crisis also taught Imperial and criminal powers the same lesson: House Ventara could control biological evidence. It could prove guilt, hide guilt, relocate guilt, or preserve guilt until the right person needed leverage.The Warden Patent made the family noble.The Orion connection made the family dangerous.Project First Hunt and the Ventaran compactWhen Project First Hunt began infiltrating criminal networks, it needed respectable partners. House Ventara supplied medical cover, biological shipping channels, animal-preserve logistics, and high-status social access.After the Chios Incident, when Project First Hunt was purged and its survivors formed the Orion Accord, Ventara faced a choice.They could expose the surviving network and risk revealing their own involvement.They could withdraw and hope the hunters forgot them.Or they could help write the rules of the hunt.They chose the third path.House Ventara became one of Orion’s founding noble pillars: not pirates, not common smugglers, but keepers of biological leverage, noble legitimacy, and hidden names.The name changeAt the founding of the Accord, the family adopted the name Ventara.The public reason was refinement: an ancient Terran keeper-family entering Imperial high nobility.The private reason was ritual. Orion’s founders liked names, masks, and chosen identities. The Accord treats identity as a negotiable asset. Under Article III, Names Are Property: false names, noble lineages, ship registries, gene records, and citizenship files can be bought, sold, inherited, or revoked.By changing Vantara to Ventara, the family did what Orion teaches.It weaponized its own name.Elevation to ducal rankHouse Ventara’s ducal rise came from a combination of public service and private leverage.Publicly, the family earned subsector-level dignity because its biological expertise was indispensable: food security, disease control, frontier medical systems, agricultural genetics, preserve law, and rare animal DNA expression.Privately, the family also held enough secrets to make itself difficult to deny.The ducal patent did not make House Ventara sovereign. It did, however, give the family exactly what Orion needed in a noble patron: legitimacy, reach, laboratories, legal authority, and access to people whose secrets were worth more than worlds.Lady Ysabel VentaraName: Lady Ysabel VentaraStatus: Current head of House VentaraSeat: Caerleon Arcology, the Caerleon March, RuieAncestral affiliation: House Ventara of AlellProfession: Brilliant biologist, xenobiologist, geneticist, noble administratorKnown child: Aurelius HolstKnown partner: Undisclosed; known only to YsabelPublic reputation: Esteemed noble scientistPrivate reputation: Keeper of secrets too dangerous to sequenceLady Ysabel Ventara is the current head of the family. Although House Ventara carries ducal rank, she is commonly styled Lady Ysabel, partly by personal preference and partly because the softer style lets her move more easily through scientific, diplomatic, and underworld-adjacent spaces.Ysabel is one of the Imperium’s most brilliant noble biologists. Her work concerns rare animal DNA expressions, disease adaptation, genetic medicine, xenobiology, military bioclinics, and biological traits that emerge only under unusual planetary stress.She is also the most dangerous kind of Ventara: a scientist who understands that a bloodline is both a living fact and a political weapon.The scandal of Aurelius HolstLady Ysabel is the mother of Aurelius Holst.His other parent is known only to Ysabel. The most accepted rumor is that Aurelius was conceived during one of Ysabel’s off-world expeditions, perhaps with a fleeting lover who never understood the dynastic consequences. More dangerous rumors suggest the lover was connected to Orion, Artemis, a rival noble house, a classified expedition, or a biological project that should not have produced a child.When Ysabel’s pregnancy became known, it caused a scandal inside House Ventara.For most noble houses, an undisclosed parent would be embarrassing.For House Ventara, it was existential.This is a family whose power rests on provenance, names, bloodlines, custody, and genetic records. An unexplained child threatened everything the house claimed to control.Ysabel disavowed Aurelius and sent him to be raised by Dr. Thaddeus Holst, a trusted physician and family friend.Publicly, this preserved the house.Privately, it followed Orion logic perfectly.If names are property, then Aurelius’s name had to be moved. If identity is a weapon, then his identity had to be disarmed. If every meaningful agreement is recorded somewhere, then the record of his birth had to be sealed, altered, or hidden.Dr. Thaddeus HolstDr. Thaddeus Holst is more than a foster father. He is a living containment system.He gave Aurelius a name, a profession, a life, and a shield against Ventaran politics. He also became the holder of a secret that could damage one of the Imperium’s most esteemed noble houses.In Orion terms, Holst may be one of three things:A loyal friend protecting a child.A Quarry who never knew he was being used.Or a Guide-adjacent neutral party whose survival is protected by private agreement.The danger is that not even Aurelius may know which version is true.The Caerleon MarchDomain: The Caerleon MarchWorld: Ruie, Spinward Marches 1905Subsector: ReginaSector: Spinward MarchesUWP: B776879-8Profile: Non-industrial, moderate law, rich worldPolitical climate: Imperial control with heavy local aristocratic influenceControlled by: House Ventara through noble jurisdiction, research concessions, medical infrastructure, and political influenceThe Caerleon March is Lady Ysabel’s active seat of power.Alell remains the ancestral heart of House Ventara, but Ruie is where Ysabel governs, experiments, negotiates, conceals, and responds to crisis.Why Ruie mattersRuie is semi-independent in character, with Imperial nobles exerting control from afar. That makes it ideal for House Ventara. It is close enough to Imperial legitimacy to protect noble operations, but ambiguous enough for local aristocratic influence, research concessions, mining settlements, medical experiments, and quiet underworld arrangements.To Imperial officials, the Caerleon March is a useful noble jurisdiction.To the common population, it is the place that brings clinics, jobs, vaccines, and agricultural stability.To Orion, it is a perfect frontier node: respectable, medically necessary, politically shielded, and hard to audit.Notable locationsCaerleon ArcologyThe main noble estate and governance center of Lady Ysabel Ventara.Caerleon Arcology is part palace, part ministry, part laboratory, part court, and part sealed archive. Its upper levels are green, ceremonial, and aristocratic. Its lower levels are clinical, secured, and compartmentalized.Public functions include governance, research administration, noble diplomacy, and biological licensing.Private functions may include Orion arbitration meetings, protected medical extractions, false identity storage, and black biological escrow.Imperial BioclinicsThe Imperial Bioclinics specialize in disease control, genetic engineering, mining-colony medicine, military medicine, and biological emergency response.They are one of Ysabel’s greatest sources of legitimacy. They save lives, especially in frontier settlements and industrial zones where ordinary medicine fails.They are also ideal Orion infrastructure.The Rigel Line specializes in impossible movement, getting people, cargo, or data across sealed borders using methods such as passenger liners, diplomatic pouches, frozen embryos, medical evacuations, salvage drones, and misregistered smallcraft.A Ventaran Bioclinic can therefore be both hospital and doorway.Helion PrimeHelion Prime is a troubled mining colony affected by disease outbreaks. It is tied to Aurelius Holst’s career-defining crisis and to Lady Ysabel’s domain.In the public version, Helion Prime is a frontier medical tragedy.In the private version, it may be a failed experiment, an Orion-protected shipment gone wrong, a biological sabotage site, a Betelgeuse provocation, or the place where Aurelius first came close to discovering why his mother erased him.The Black Hound ScandalA Ventaran cadet branch attempted to create a proprietary line of bonded hunting-beasts using restricted genetic material held under house custody. The project violated Imperial biological law, but its deeper offense was against the Accord: the cadet branch used protected material without proper Orion recognition, profit-sharing, or arbitration.When the animals displayed unexpected intelligence and loyalty structures, the scandal threatened several parties at once: House Ventara, the Green Vault, Orion’s illegal biotech markets, and noble patrons who had funded the research through shell structures.The main line destroyed the project publicly.Privately, it preserved the best results.This is why the xeno-hounds remain as supporters on the crest. They are not merely loyal beasts. They are a warning: House Ventara breeds its monsters, collars them, and calls that civilization.The Orion divisions that matter most to House VentaraHouse Ventara does not control the Orion Accord. It is too vast, too distributed, and too ritualized for any one house to command. The Accord avoids formal titles that investigators can map, using mythic and ambiguous structures instead.But several Orion divisions intersect directly with Ventaran power.Mintaka — WealthMintaka manages finance, laundering, trade fraud, shell companies, debt ledgers, bond manipulation, and noble investment channels.House Ventara’s research concessions, clinics, preserves, agricultural patents, and medical supply contracts are perfect places to hide money.Alnilam — InformationAlnilam manages blackmail archives, intelligence markets, identity fabrication, encrypted communications, and secrets recovered from Imperial systems.House Ventara’s genetic archives are information in biological form. A blood sample can be blackmail. A parentage record can topple a marriage alliance. A disease profile can expose an illegal experiment.Oenopion DivisionOenopion handles blindness: forgery, legal sabotage, false evidence, erased files, memory manipulation, witness corruption, sensor spoofing, and bureaucratic misdirection. Its operations include creating false noble genealogies, erasing people from medical and travel records, and manipulating evidence.If Aurelius Holst’s birth records were altered, Oenopion methods are the obvious tool.Merope NetworkMerope specializes in desire: social engineering, elite compromise, marriage contracts, romantic manipulation, court gossip, salons, vice markets, and diplomatic seduction. It compromises people by offering exactly what they believe they deserve.Ysabel’s unknown lover may have been a private mistake.Or she may have been the target, beneficiary, or author of a Merope operation.Eos InitiativeThe Eos Initiative recruits people when their old lives end: disgraced officers, bankrupt merchants, exiled nobles, betrayed intelligence assets, survivors of scandals, and talented people abandoned by Imperial institutions. Its favorite line is: “The Empire used you. We will pay you.”Aurelius Holst is exactly the kind of person Eos would watch.A disavowed noble child, raised outside his house, wounded by scandal, shaped by medical crisis, and tied to a powerful mother who denied him — that is not merely a person.To Orion, that is a recruitable grievance.Lady Ysabel’s current political problemLady Ysabel rules from Caerleon Arcology with brilliance, caution, and unresolved guilt.Her formal problem is maintaining House Ventara’s public identity: ducal, scientific, useful, Imperial, and respectable.Her private problem is managing the family’s Orion inheritance.Her personal problem is Aurelius.Aurelius Holst is not only a son she disavowed. He is a contradiction made flesh. House Ventara claims that provenance matters, names matter, and living inheritance must never be erased. Yet Ysabel erased her own child from the house record.The Orion Accord makes this even more dangerous.Under Orion doctrine, names are property. Records endure. Debts are sacred. Identity is a weapon. If the Accord recognizes a contract, the contract is real.Somewhere, someone may hold the true record of Aurelius Holst.If that record is recognized by Orion, then Aurelius is not merely a scandal.He is a debt.Factions inside House VentaraThe High AntlerThe ducal line and formal ruling branch. Loyal to the house patent, the Green Vault, and the continuity of Ventaran authority. Publicly, the High Antler supports Lady Ysabel. Privately, some members believe her scandal has endangered the family’s legitimacy.The Green Vault TraditionalistsCentered on Alell. They believe House Ventara has drifted too far from stewardship and too close to black medicine, underworld logistics, and Ruie-based political ambiguity. They want the family’s public honor preserved, even if that means sacrificing Ysabel.The Caerleon ModernistsCentered on Ruie. They support Ysabel’s aggressive medical research, mining-colony interventions, military bioclinics, and frontier authority. They argue that the family survives by being useful, not pure.The Orion KinA hidden faction within the house that believes Ventara’s true strength has always come from the Accord. They regard public Imperial nobility as a mask and Orion as the deeper law.The Aurelius QuestionNot a formal faction yet, but a growing anxiety.Some want Aurelius protected.Some want him erased.Some want him studied.Some want him acknowledged and used as leverage against Ysabel.Some want to know who his other parent is before deciding.RumorsThe Green Vault contains a true Black Star Stone from the founding of the Orion Accord.House Ventara’s three-star crest is also a coded Orion recognition mark.Ysabel’s unknown lover was a Merope operative, and the affair was never accidental.Aurelius Holst’s medical records have been altered by an Oenopion cell.Dr. Thaddeus Holst holds the only honest copy of Aurelius’s birth record.Helion Prime’s plague was caused by an Orion-protected biotech shipment routed through Ventaran medical cover.Aurelius’s blood carries a genetic marker tied to Project First Hunt.The Caerleon Arcology contains a private Orion arbitration chamber beneath its public court.A Ventaran cadet branch has been named Orion Fallen, and the Scorpion Protocol is already moving.One of the Pleiades Vaults contains noble bloodlines, Imperial intelligence crimes, megacorporate illegal research, deep-cover Orion identities, and perhaps the truth of Project First Hunt. House Ventara may be guarding, searching for, or hiding one of those vaults.Campaign useHouse Ventara works best as a noble house with three faces.To the public, they are brilliant biological stewards.To the Imperium, they are useful, prestigious, and difficult to prosecute.To Orion, they are old blood.Lady Ysabel Ventara may hire the Travellers to recover a stolen gene-sample, escort a plague cure to Helion Prime, protect Aurelius without revealing why, retrieve Dr. Holst, audit a compromised Bioclinic, or quietly destroy a Black Star Stone before Artemis or Orion finds it.She may be patron, antagonist, mother, scientist, liar, victim of manipulation, or architect of her own tragedy.Aurelius Holst is the emotional and political key. Through him, the campaign can expose the central hypocrisy of House Ventara:The house that preserves every living inheritance tried to erase its own.And under the Orion Accord, erased things do not stay erased.The stars remember.", "content_html": "Formal house name: House Ventara</br>Ancestral seat: Alell, Spinward Marches 1706</br>Current active domain: The Caerleon March, Ruie, Spinward Marches 1905</br>Current head: Lady Ysabel Ventara</br>House rank: Ducal family, with subsector-scale Imperial standing</br>Public vocation: Bioengineering, xenobiology, conservation law, agricultural genetics, disease control, military medicine, and rare animal DNA research</br>Secret vocation: Biological laundering, illegal gene-line custody, black medical infrastructure, noble identity manipulation, and Orion Accord arbitration support</br>Public motto: We Keep What Lives</br>Private Ventaran maxim: The keeper knows which gates are real.</br>Orion phrase known to the inner house: The hunter belongs to no king. The Accord’s darker internal version is All worlds are hunting grounds.
House Ventara is an old Imperial noble family built on a contradiction. Publicly, it is a ducal house of science, stewardship, and lawful biological administration. Privately, it is one of the aristocratic pillars that helped give the Orion Accord respectability, money, laboratories, medical cover, and access to noble bloodlines.
The Ventaras do not think of themselves as common criminals. That is part of the problem.
They think of themselves as keepers: keepers of life, keepers of bloodlines, keepers of secrets, keepers of dangerous contracts, and keepers of names.
The official Ventaran history says that the family helped found the Orion Accords, a framework for regulating rare animal genetic material, biological patents, interstellar specimen custody, and the movement of dangerous lifeforms across borders.
That version is taught to junior relatives, polite allies, and most retainers.
It is not wholly false.
It is simply the respectable skin over something older and darker.
The true Orion Accord began as a criminal compact descended from Project First Hunt, a covert Imperial Intelligence program created to infiltrate organized crime. The project was given ships, shell companies, forged identities, dead-drop systems, corrupt port identities, and enough autonomy to look real. It was allowed to conduct controlled crimes, launder funds, and recruit real criminals as disposable assets.
Then Project First Hunt escaped its leash.
After the Chios Incident, when an Imperial patron attempted to shut the project down, the surviving officers and assets used their ships, contacts, secrets, and proof of Imperial complicity to form a mutual-defense compact. That compact became the Orion Accord.
House Ventara entered this history through biology.
At first, the Vantaras were useful to Imperial Intelligence because they could move animals, embryos, disease samples, livestock lines, medical cultures, and genetic archives without attracting the same suspicion as weapons or bullion. A sealed animal shipment, a quarantine transport, a veterinary mission, or a noble preserve transfer could hide almost anything.
Over time, Ventaran preserve law, gene-bank custody, and noble medical networks became perfect cover for Orion operations.
The family did not merely join the Accord.
It helped make parts of the Accord invisible.
Before the family was noble, it was known as Vantara.
The Vantaras traced their identity to ancient Terra, where their ancestors were gamekeepers and wardens of animal preserves. They managed valuable beasts, guarded breeding lines, prevented poaching, maintained preserves, and knew that the boundary between civilization and the wild was always political.
This origin matters because the Orion Accord is built around hunting mythology. To Orion, criminality is not shameful; it is proof that one has “outgrown permission.”
When the family later changed its name from Vantara to Ventara, the public explanation was that the new name marked its transformation from Terran gamekeepers into Imperial biological stewards.
The private explanation is sharper.
The family chose Ventara when it bound itself to Orion because the old Vantara name meant keeper, warden, tracker, and master of preserves. The Orion founders loved the symbolism. The former gamekeepers became aristocratic custodians of the hunt.
That is why Ventaran heraldry is filled with antlers, hounds, stars, and chains of custody.
To outsiders, these are noble symbols.
To Orion, they are a confession.
![\"House](\"/img/2026-07/house-ventara-Coat-of-Arms.webp\")
Sable, upon a field of stars, a stag’s head cabossed Or, attired Or, between the attires a double helix Argent and Or; in chief three stars conjoined in the figure of Orion; in base a world Vert within orbital rings Argent. The shield ensigned by a ducal coronet and supported by two collared xeno-hounds Sable and Vert, armed and gorged Or.
In plain language: a dark shield shows a golden stag, a DNA helix between its antlers, three Orion stars above, and a green world with orbital rings below. The shield is crowned with a ducal coronet and flanked by two elegant alien hunting beasts.
The coronet marks House Ventara’s hereditary ducal status. It is a lawful Imperial symbol and indicates subsector-level dignity. It does not imply that House Ventara owns Alell, Ruie, or the Regina subsector. The house rules through patent, influence, estate rights, research concessions, and Imperial recognition.
The black field represents space, frontier duty, secrecy, and scientific work conducted far from the Core. Publicly, it suggests noble service in dangerous regions of the Imperium.
The stag represents the family’s ancient Vantara identity as Terran gamekeepers. Publicly, it means stewardship, conservation, discipline, and watchfulness.
The helix represents modern Ventaran bioengineering: disease control, rare genetic expression, agricultural science, xenobiology, military medicine, and the harvesting of unique animal DNA from across known space.
Publicly, the three stars are explained as the Orion legacy: the family’s ancient role in interstellar biological regulation and scientific diplomacy.
The green world represents Alell: the ancestral seat, agricultural wealth, preserve culture, and the Green Vault.
The rings represent interstellar provenance: the lawful movement of specimens, embryos, gene-lines, and biological archives from world to world.
The hounds represent fieldwork, hunting, tracking, quarantine enforcement, and house loyalty. Their collars mean discipline and restraint.
To an initiate of the Accord, the same crest says something very different.
The most important Orion symbol is the Black Star Stone, a polished black gemstone or synthetic crystal containing a faint embedded pattern of Orion’s constellation. Cheap versions are fashion; real ones can contain dead-drop coordinates, decryption keys, membership proof, hidden account addresses, debts, kill authorizations, or fragments of old Project First Hunt command architecture.
The starry black shield of House Ventara can therefore be read as a noble-scale Black Star Stone.
It says: this house is under Orion protection.
The Accord’s common sign is three slow taps: table, chest, table. The meaning is Debt, Name, Ground: all things have price, identity is a weapon, and every place belongs to whoever can hold it.
On the crest, the three Orion stars are not merely astronomical. They are a criminal doctrine hidden in heraldry.
For House Ventara:
Debt means every cure, sample, favor, and rescue has a price.Name means bloodline, identity, legitimacy, and parentage can be concealed or weaponized.Ground means a preserve, clinic, mine, colony, or world belongs in practice to whoever can control its life-supporting systems.
Publicly, the stag is stewardship.
Privately, it is the hunt.
The Accord’s full members are called Hunters: smugglers, thieves, killers, pirates, brokers, ship captains, intrusion specialists, and criminal troubleshooters who have recognized standing under the Accord and may invoke its arbitration.
House Ventara’s genius is that it made the hunter look like a keeper.
The helix represents legal science in public, but illegal biotech in private. The Accord protects illegal biotech houses, noble patrons, black financiers, and criminal networks operating beneath respectable society.
For Ventara, the helix means more than discovery. It means biological custody that cannot be challenged in public court because the true contract is held by Orion.
Publicly, the rings represent lawful interstellar provenance.
Privately, they represent Orion movement networks. The Poseidon Fleet controls illegal movement through obscure ports, gas giant refueling shadows, misfiled naval tenders, salvage claims, abandoned scout stations, old war caches, and emergency medical transports used as cover.
A Ventaran medical transport may be exactly what it claims to be.
It may also be moving a person, sample, debt marker, or false identity under Orion protection.
The hounds represent field operatives and biological instruments. Their collars are not just loyalty. They are procedure.
The Orion Accord allows criminal competition, but forbids destructive conflict without sanction. Members may not hunt another Hunter without leave, and disputes are supposed to be handled through arbitration.
The collared hound means: violence is permitted, but only when the hunt has been authorized.
During human expansion into the stars, the Vantara family survived as biological specialists: preserve planners, ecological surveyors, shipboard livestock officers, gene-bank custodians, and quarantine consultants.
They learned how to move life safely.
That also taught them how to move life secretly.
By the time Imperial Intelligence created Project First Hunt, the Vantaras already had the perfect professional mask. No one looked twice at a noble biological expedition, a disease-control mission, a gene-bank transfer, or a quarantine shipment.
The family’s earliest criminal value was not piracy.
It was plausible legitimacy.
House Ventara rose to power on Alell, a wealthy agricultural world suited to noble biological ambition, scientific enclaves, and Imperial-sanctioned bio-experiments. Alell became the family’s ancestral seat because it offered three things Ventara needed: agricultural wealth, isolation, and official respectability.
The family seat on Alell became known as the Green Vault.
Publicly, the Green Vault is a palace, archive, research university, gene-bank, and preserve authority.
Privately, some of its sealed collections are believed to include Orion-protected samples, illegal noble bloodline records, biological blackmail, and genetic evidence that cannot safely enter Imperial courts.
This connects House Ventara to one of the Accord’s most dangerous principles: The Stars Remember. Orion believes all major agreements are recorded somewhere, even if the record is hidden. This belief is the basis for the Accord’s blackmail culture.
The Green Vault is one such place where the stars remember.
The first Ventaran patent was granted after the family contained a biological crisis involving contaminated livestock imports, illegal trophy-beast embryos, and ecological damage that more powerful interests tried to conceal.
Publicly, the Vantaras were rewarded for competence and incorruptibility.
Privately, the crisis also taught Imperial and criminal powers the same lesson: House Ventara could control biological evidence. It could prove guilt, hide guilt, relocate guilt, or preserve guilt until the right person needed leverage.
The Warden Patent made the family noble.
The Orion connection made the family dangerous.
When Project First Hunt began infiltrating criminal networks, it needed respectable partners. House Ventara supplied medical cover, biological shipping channels, animal-preserve logistics, and high-status social access.
After the Chios Incident, when Project First Hunt was purged and its survivors formed the Orion Accord, Ventara faced a choice.
They could expose the surviving network and risk revealing their own involvement.
They could withdraw and hope the hunters forgot them.
Or they could help write the rules of the hunt.
They chose the third path.
House Ventara became one of Orion’s founding noble pillars: not pirates, not common smugglers, but keepers of biological leverage, noble legitimacy, and hidden names.
At the founding of the Accord, the family adopted the name Ventara.
The public reason was refinement: an ancient Terran keeper-family entering Imperial high nobility.
The private reason was ritual. Orion’s founders liked names, masks, and chosen identities. The Accord treats identity as a negotiable asset. Under Article III, Names Are Property: false names, noble lineages, ship registries, gene records, and citizenship files can be bought, sold, inherited, or revoked.
By changing Vantara to Ventara, the family did what Orion teaches.
It weaponized its own name.
House Ventara’s ducal rise came from a combination of public service and private leverage.
Publicly, the family earned subsector-level dignity because its biological expertise was indispensable: food security, disease control, frontier medical systems, agricultural genetics, preserve law, and rare animal DNA expression.
Privately, the family also held enough secrets to make itself difficult to deny.
The ducal patent did not make House Ventara sovereign. It did, however, give the family exactly what Orion needed in a noble patron: legitimacy, reach, laboratories, legal authority, and access to people whose secrets were worth more than worlds.
Name: Lady Ysabel VentaraStatus: Current head of House VentaraSeat: Caerleon Arcology, the Caerleon March, RuieAncestral affiliation: House Ventara of AlellProfession: Brilliant biologist, xenobiologist, geneticist, noble administratorKnown child: Aurelius HolstKnown partner: Undisclosed; known only to YsabelPublic reputation: Esteemed noble scientistPrivate reputation: Keeper of secrets too dangerous to sequence
Lady Ysabel Ventara is the current head of the family. Although House Ventara carries ducal rank, she is commonly styled Lady Ysabel, partly by personal preference and partly because the softer style lets her move more easily through scientific, diplomatic, and underworld-adjacent spaces.
Ysabel is one of the Imperium’s most brilliant noble biologists. Her work concerns rare animal DNA expressions, disease adaptation, genetic medicine, xenobiology, military bioclinics, and biological traits that emerge only under unusual planetary stress.
She is also the most dangerous kind of Ventara: a scientist who understands that a bloodline is both a living fact and a political weapon.
Lady Ysabel is the mother of Aurelius Holst.
His other parent is known only to Ysabel. The most accepted rumor is that Aurelius was conceived during one of Ysabel’s off-world expeditions, perhaps with a fleeting lover who never understood the dynastic consequences. More dangerous rumors suggest the lover was connected to Orion, Artemis, a rival noble house, a classified expedition, or a biological project that should not have produced a child.
When Ysabel’s pregnancy became known, it caused a scandal inside House Ventara.
For most noble houses, an undisclosed parent would be embarrassing.
For House Ventara, it was existential.
This is a family whose power rests on provenance, names, bloodlines, custody, and genetic records. An unexplained child threatened everything the house claimed to control.
Ysabel disavowed Aurelius and sent him to be raised by Dr. Thaddeus Holst, a trusted physician and family friend.
Publicly, this preserved the house.
Privately, it followed Orion logic perfectly.
If names are property, then Aurelius’s name had to be moved. If identity is a weapon, then his identity had to be disarmed. If every meaningful agreement is recorded somewhere, then the record of his birth had to be sealed, altered, or hidden.
Dr. Thaddeus Holst is more than a foster father. He is a living containment system.
He gave Aurelius a name, a profession, a life, and a shield against Ventaran politics. He also became the holder of a secret that could damage one of the Imperium’s most esteemed noble houses.
In Orion terms, Holst may be one of three things:
A loyal friend protecting a child.A Quarry who never knew he was being used.Or a Guide-adjacent neutral party whose survival is protected by private agreement.
The danger is that not even Aurelius may know which version is true.
Domain: The Caerleon MarchWorld: Ruie, Spinward Marches 1905Subsector: ReginaSector: Spinward MarchesUWP: B776879-8Profile: Non-industrial, moderate law, rich worldPolitical climate: Imperial control with heavy local aristocratic influenceControlled by: House Ventara through noble jurisdiction, research concessions, medical infrastructure, and political influence
The Caerleon March is Lady Ysabel’s active seat of power.
Alell remains the ancestral heart of House Ventara, but Ruie is where Ysabel governs, experiments, negotiates, conceals, and responds to crisis.
Ruie is semi-independent in character, with Imperial nobles exerting control from afar. That makes it ideal for House Ventara. It is close enough to Imperial legitimacy to protect noble operations, but ambiguous enough for local aristocratic influence, research concessions, mining settlements, medical experiments, and quiet underworld arrangements.
To Imperial officials, the Caerleon March is a useful noble jurisdiction.
To the common population, it is the place that brings clinics, jobs, vaccines, and agricultural stability.
To Orion, it is a perfect frontier node: respectable, medically necessary, politically shielded, and hard to audit.
The main noble estate and governance center of Lady Ysabel Ventara.
Caerleon Arcology is part palace, part ministry, part laboratory, part court, and part sealed archive. Its upper levels are green, ceremonial, and aristocratic. Its lower levels are clinical, secured, and compartmentalized.
Public functions include governance, research administration, noble diplomacy, and biological licensing.
Private functions may include Orion arbitration meetings, protected medical extractions, false identity storage, and black biological escrow.
The Imperial Bioclinics specialize in disease control, genetic engineering, mining-colony medicine, military medicine, and biological emergency response.
They are one of Ysabel’s greatest sources of legitimacy. They save lives, especially in frontier settlements and industrial zones where ordinary medicine fails.
They are also ideal Orion infrastructure.
The Rigel Line specializes in impossible movement, getting people, cargo, or data across sealed borders using methods such as passenger liners, diplomatic pouches, frozen embryos, medical evacuations, salvage drones, and misregistered smallcraft.
A Ventaran Bioclinic can therefore be both hospital and doorway.
Helion Prime is a troubled mining colony affected by disease outbreaks. It is tied to Aurelius Holst’s career-defining crisis and to Lady Ysabel’s domain.
In the public version, Helion Prime is a frontier medical tragedy.
In the private version, it may be a failed experiment, an Orion-protected shipment gone wrong, a biological sabotage site, a Betelgeuse provocation, or the place where Aurelius first came close to discovering why his mother erased him.
A Ventaran cadet branch attempted to create a proprietary line of bonded hunting-beasts using restricted genetic material held under house custody. The project violated Imperial biological law, but its deeper offense was against the Accord: the cadet branch used protected material without proper Orion recognition, profit-sharing, or arbitration.
When the animals displayed unexpected intelligence and loyalty structures, the scandal threatened several parties at once: House Ventara, the Green Vault, Orion’s illegal biotech markets, and noble patrons who had funded the research through shell structures.
The main line destroyed the project publicly.
Privately, it preserved the best results.
This is why the xeno-hounds remain as supporters on the crest. They are not merely loyal beasts. They are a warning: House Ventara breeds its monsters, collars them, and calls that civilization.
House Ventara does not control the Orion Accord. It is too vast, too distributed, and too ritualized for any one house to command. The Accord avoids formal titles that investigators can map, using mythic and ambiguous structures instead.
But several Orion divisions intersect directly with Ventaran power.
Mintaka manages finance, laundering, trade fraud, shell companies, debt ledgers, bond manipulation, and noble investment channels.
House Ventara’s research concessions, clinics, preserves, agricultural patents, and medical supply contracts are perfect places to hide money.
Alnilam manages blackmail archives, intelligence markets, identity fabrication, encrypted communications, and secrets recovered from Imperial systems.
House Ventara’s genetic archives are information in biological form. A blood sample can be blackmail. A parentage record can topple a marriage alliance. A disease profile can expose an illegal experiment.
Oenopion handles blindness: forgery, legal sabotage, false evidence, erased files, memory manipulation, witness corruption, sensor spoofing, and bureaucratic misdirection. Its operations include creating false noble genealogies, erasing people from medical and travel records, and manipulating evidence.
If Aurelius Holst’s birth records were altered, Oenopion methods are the obvious tool.
Merope specializes in desire: social engineering, elite compromise, marriage contracts, romantic manipulation, court gossip, salons, vice markets, and diplomatic seduction. It compromises people by offering exactly what they believe they deserve.
Ysabel’s unknown lover may have been a private mistake.
Or she may have been the target, beneficiary, or author of a Merope operation.
The Eos Initiative recruits people when their old lives end: disgraced officers, bankrupt merchants, exiled nobles, betrayed intelligence assets, survivors of scandals, and talented people abandoned by Imperial institutions. Its favorite line is: “The Empire used you. We will pay you.”
Aurelius Holst is exactly the kind of person Eos would watch.
A disavowed noble child, raised outside his house, wounded by scandal, shaped by medical crisis, and tied to a powerful mother who denied him — that is not merely a person.
To Orion, that is a recruitable grievance.
Lady Ysabel rules from Caerleon Arcology with brilliance, caution, and unresolved guilt.
Her formal problem is maintaining House Ventara’s public identity: ducal, scientific, useful, Imperial, and respectable.
Her private problem is managing the family’s Orion inheritance.
Her personal problem is Aurelius.
Aurelius Holst is not only a son she disavowed. He is a contradiction made flesh. House Ventara claims that provenance matters, names matter, and living inheritance must never be erased. Yet Ysabel erased her own child from the house record.
The Orion Accord makes this even more dangerous.
Under Orion doctrine, names are property. Records endure. Debts are sacred. Identity is a weapon. If the Accord recognizes a contract, the contract is real.
Somewhere, someone may hold the true record of Aurelius Holst.
If that record is recognized by Orion, then Aurelius is not merely a scandal.
He is a debt.
The ducal line and formal ruling branch. Loyal to the house patent, the Green Vault, and the continuity of Ventaran authority. Publicly, the High Antler supports Lady Ysabel. Privately, some members believe her scandal has endangered the family’s legitimacy.
Centered on Alell. They believe House Ventara has drifted too far from stewardship and too close to black medicine, underworld logistics, and Ruie-based political ambiguity. They want the family’s public honor preserved, even if that means sacrificing Ysabel.
Centered on Ruie. They support Ysabel’s aggressive medical research, mining-colony interventions, military bioclinics, and frontier authority. They argue that the family survives by being useful, not pure.
A hidden faction within the house that believes Ventara’s true strength has always come from the Accord. They regard public Imperial nobility as a mask and Orion as the deeper law.
Not a formal faction yet, but a growing anxiety.
Some want Aurelius protected.
Some want him erased.
Some want him studied.
Some want him acknowledged and used as leverage against Ysabel.
Some want to know who his other parent is before deciding.
The Green Vault contains a true Black Star Stone from the founding of the Orion Accord.
House Ventara’s three-star crest is also a coded Orion recognition mark.
Ysabel’s unknown lover was a Merope operative, and the affair was never accidental.
Aurelius Holst’s medical records have been altered by an Oenopion cell.
Dr. Thaddeus Holst holds the only honest copy of Aurelius’s birth record.
Helion Prime’s plague was caused by an Orion-protected biotech shipment routed through Ventaran medical cover.
Aurelius’s blood carries a genetic marker tied to Project First Hunt.
The Caerleon Arcology contains a private Orion arbitration chamber beneath its public court.
A Ventaran cadet branch has been named Orion Fallen, and the Scorpion Protocol is already moving.
One of the Pleiades Vaults contains noble bloodlines, Imperial intelligence crimes, megacorporate illegal research, deep-cover Orion identities, and perhaps the truth of Project First Hunt. House Ventara may be guarding, searching for, or hiding one of those vaults.
House Ventara works best as a noble house with three faces.
To the public, they are brilliant biological stewards.
To the Imperium, they are useful, prestigious, and difficult to prosecute.
To Orion, they are old blood.
Lady Ysabel Ventara may hire the Travellers to recover a stolen gene-sample, escort a plague cure to Helion Prime, protect Aurelius without revealing why, retrieve Dr. Holst, audit a compromised Bioclinic, or quietly destroy a Black Star Stone before Artemis or Orion finds it.
She may be patron, antagonist, mother, scientist, liar, victim of manipulation, or architect of her own tragedy.
Aurelius Holst is the emotional and political key. Through him, the campaign can expose the central hypocrisy of House Ventara:
The house that preserves every living inheritance tried to erase its own.
And under the Orion Accord, erased things do not stay erased.
The stars remember.
", "url": "https://tedt.org/House-Ventara-of-Alell-and-the-Caerleon-March/", "image": "/img/2026-07/house-ventara.webp", "tags": ["RPG","TTRPG","Traveller","Campaign Design","Worldbuilding","Noble Houses","Factions","Game Mastering","Space Opera","Frontier Intrigue","Orion Accord"], "date_published": "2026-07-04T00:00:00-07:00", "date_modified": "2026-07-04T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/UGS-1-Unicode-Glyph-Variant-Steganography/", "title": "UGS-1: Unicode Glyph-Variant Steganography, Version 1.1", "summary": "UGS-1 is a compact technical specification for embedding framed byte payloads in visible text by replacing selected Latin characters with visually similar Unicode homoglyphs. It defines security constraints, non-goals, Unicode handling rules, framing, validation, capacity, APIs, and detector guidance.", "content_text": "1. Status and Security NoticeUGS-1 is a deterministic, low-bandwidth steganographic encoding for hiding a byte payload inside visible text by replacing selected Latin characters with visually similar Unicode characters.UGS-1 is not encryption, authentication, or tamper protection. The CRC in this specification only detects accidental corruption. Anyone who understands the format can alter the payload and recompute the CRC.If secrecy or tamper resistance is required, applications should encrypt and authenticate the payload before placing it in a UGS-1 frame, for example with an AEAD scheme.UGS-1 data is fragile. Editors, messaging systems, source-control tools, spellcheckers, security gateways, LLM rewrites, transliteration tools, ASCII sanitizers, and confusable-character detectors may modify or remove the channel.Unicode’s own security guidance discusses confusable characters and mechanisms for detecting them, so UGS-1 should be treated as a technique with security implications.Reference: https://www.unicode.org/reports/tr39/2. GoalUGS-1 embeds a hidden byte payload inside visible text.Conceptual example:Latin a U+0061 encodes bit 0Cyrillic а U+0430 encodes bit 1Both glyphs may appear visually similar:aBut they are different Unicode code points.UGS-1 profile H1 encodes one bit per eligible visible character.3. Non-GoalsUGS-1 does not provide:confidentialityauthenticationintegrity against deliberate tamperingplausible deniabilityrobust survival through arbitrary text processinghigh bandwidthUGS-1 is intended to be simple, deterministic, testable, and easy to detect or remove when needed.4. TerminologyCover textThe visible text before embedding.Carrier textThe visible text after embedding.PayloadThe hidden message as raw bytes.Text payloadA payload interpreted as UTF-8 text.Eligible characterA code point that appears in the UGS-1 H1 homoglyph table.Zero variantThe ordinary Latin code point used to encode bit 0.One variantThe visually similar Unicode code point used to encode bit 1.FrameThe structured binary data embedded into the carrier text.Variant resetThe process of replacing UGS-1 one variants with their corresponding zero variants before embedding. This is UGS-specific and must not be confused with Unicode normalization.5. Required Unicode HandlingImplementations MUST operate on Unicode scalar values or code points, not encoded bytes.Implementations MUST NOT iterate through UTF-16 strings in a way that incorrectly splits surrogate pairs. Profile H1 only uses BMP code points, but code-point handling keeps implementations portable.Implementations MUST NOT normalize, case-fold, transliterate, ASCII-clean, confusable-map, or sanitize the carrier text after embedding.Unicode normalization forms such as NFC, NFD, NFKC, and NFKD do not generally fold Cyrillic homoglyphs into Latin letters. However, other security and text-processing systems may do so. The larger practical risks are transliteration, ASCII filtering, confusable-skeleton mapping, spellcheck, OCR, LLM rewriting, and security sanitization.Implementations SHOULD test the intended transport channel before use.Reference: https://www.unicode.org/reports/tr15/6. Structured Text WarningApplications SHOULD avoid embedding into syntax-sensitive regions, including:URLsemail addressesdomain namessource codeidentifiersHTML tags and attributesMarkdown syntaxJSON keysYAML keysCSV headersshell commandsdatabase queriesfilenamescryptographic materialFor HTML, XML, Markdown, or rich-text formats, applications SHOULD embed only in visible prose text nodes, not in markup or syntax.Replacing Latin letters with homoglyphs can preserve visual appearance while changing program behavior.7. Profile H1: Binary Homoglyph EncodingUGS-1 H1 encodes one bit per eligible character.bit 0 -> use the Latin zero variantbit 1 -> use the homoglyph one variant7.1 Mandatory Homoglyph TableAll UGS-1 H1 implementations MUST support this exact table. Bit 0 Latin Code point Bit 1 homoglyph Code point Bit-1 character name A U+0041 А U+0410 Cyrillic Capital Letter A a U+0061 а U+0430 Cyrillic Small Letter A B U+0042 В U+0412 Cyrillic Capital Letter Ve C U+0043 С U+0421 Cyrillic Capital Letter Es c U+0063 с U+0441 Cyrillic Small Letter Es E U+0045 Е U+0415 Cyrillic Capital Letter Ie e U+0065 е U+0435 Cyrillic Small Letter Ie H U+0048 Н U+041D Cyrillic Capital Letter En I U+0049 І U+0406 Cyrillic Capital Letter Byelorussian-Ukrainian I i U+0069 і U+0456 Cyrillic Small Letter Byelorussian-Ukrainian I J U+004A Ј U+0408 Cyrillic Capital Letter Je j U+006A ј U+0458 Cyrillic Small Letter Je K U+004B К U+041A Cyrillic Capital Letter Ka M U+004D М U+041C Cyrillic Capital Letter Em O U+004F О U+041E Cyrillic Capital Letter O o U+006F о U+043E Cyrillic Small Letter O P U+0050 Р U+0420 Cyrillic Capital Letter Er p U+0070 р U+0440 Cyrillic Small Letter Er T U+0054 Т U+0422 Cyrillic Capital Letter Te X U+0058 Х U+0425 Cyrillic Capital Letter Ha x U+0078 х U+0445 Cyrillic Small Letter Ha y U+0079 у U+0443 Cyrillic Small Letter U This table intentionally avoids many tempting lookalikes that are more font-dependent.8. Frame FormatThe payload is wrapped in a binary frame.All multi-bit fields are encoded most-significant bit first.All multi-byte integers are encoded big-endian.8.1 LayoutMAGIC 16 bitsVERSION 4 bitsFLAGS 4 bitsLENGTH 24 bitsPAYLOAD 8 * LENGTH bitsCRC16 16 bitsTotal overhead:64 bitsRequired capacity:required_bits = 64 + 8 * payload_length_in_bytes8.2 MAGICFixed value:0xAD53Binary:10101101 010100118.3 VERSIONFor this specification:0x1Encoded as 4 bits:00018.4 FLAGSFor this specification:0x0Encoded as 4 bits:0000All nonzero flag values are reserved.A decoder MUST reject frames with unknown nonzero flags unless explicitly configured to support an extension.8.5 LENGTHLENGTH is a 24-bit unsigned integer.It gives the number of payload bytes.Maximum representable payload size:16,777,215 bytesPractical payload size is usually much smaller because the cover text must contain enough eligible characters.Decoders SHOULD support a configurable maximum accepted payload size.8.6 PAYLOADThe payload is raw bytes.For ordinary text messages, the payload MUST be UTF-8 encoded text without a byte-order mark.8.7 CRC16CRC-16/CCITT-FALSE is computed over:VERSION_FLAGS || LENGTH || PAYLOADWhere:VERSION_FLAGS = one byte: high nibble VERSION, low nibble FLAGSFor UGS-1 v1 with flags 0:VERSION_FLAGS = 0x10CRC parameters:Name: CRC-16/CCITT-FALSEWidth: 16Polynomial: 0x1021Initial: 0xFFFFRefIn: falseRefOut: falseXorOut: 0x0000Output: big-endianNormative pseudocode:function crc16_ccitt_false(bytes): crc = 0xFFFF for b in bytes: crc = crc XOR (b << 8) repeat 8 times: if (crc AND 0x8000) != 0: crc = ((crc << 1) XOR 0x1021) AND 0xFFFF else: crc = (crc << 1) AND 0xFFFF return crc9. Payload PreparationFor a text message:payload_bytes = UTF8_ENCODE(hidden_message)Then construct:version_flags = 0x10length = 24-bit big-endian byte lengthcrc_input = version_flags || length || payload_bytescrc = CRC16_CCITT_FALSE(crc_input)frame_bytes = 0xAD 0x53 || version_flags || length || payload_bytes || crcframe_bits = frame_bytes as bits, MSB firstExample hidden message:OKUTF-8 payload bytes:4F 4BFrame bytes:AD 53 10 00 00 02 4F 4B 9E A9Frame bits:10101101 01010011 00010000 00000000 0000000000000010 01001111 01001011 10011110 1010100110. Encoder AlgorithmInput:cover_textpayload_bytesOutput:carrier_textAlgorithm:1. Build the UGS-1 frame.2. Convert frame bytes to frame bits, MSB first.3. Reset UGS-1 variants in the cover text: For every code point: if it is a one variant from the H1 table: replace it with its corresponding zero variant else: leave it unchanged4. Count capacity: capacity_bits = number of code points in the reset cover text that are zero variants in the H1 table5. If capacity_bits < frame_bits.length: fail with INSUFFICIENT_CAPACITY6. Initialize bit_index = 0.7. For each code point cp in the reset cover text: if cp is not a zero variant in the H1 table: output cp continue if bit_index >= frame_bits.length: output cp continue bit = frame_bits[bit_index] if bit == 0: output cp if bit == 1: output corresponding one variant bit_index = bit_index + 18. Return the output text.The encoder MUST NOT alter non-eligible characters except when resetting recognized one variants to their corresponding zero variants.The encoder SHOULD reset variants before embedding so that accidental pre-existing homoglyphs do not become hidden bits.11. Decoder AlgorithmInput:carrier_textOutput:payload_bytes11.1 Bit Extraction1. Initialize bits = empty list.2. For each code point cp in carrier_text: if cp is a zero variant in the H1 table: append bit 0 to bits else if cp is a one variant in the H1 table: append bit 1 to bits else: ignore cp11.2 Strict Frame DecodeStrict mode assumes the frame starts at the first extracted bit.1. If bits.length < 64: fail with NO_FRAME2. Read first 16 bits as MAGIC. If MAGIC != 0xAD53: fail with BAD_MAGIC3. Read next 4 bits as VERSION. If VERSION != 1: fail with UNSUPPORTED_VERSION4. Read next 4 bits as FLAGS. If FLAGS != 0: fail with UNSUPPORTED_FLAGS5. Read next 24 bits as LENGTH.6. required_bits = 64 + 8 * LENGTH7. If required_bits > bits.length: fail with INCOMPLETE_FRAME8. If LENGTH exceeds the implementation's configured maximum payload size: fail with PAYLOAD_TOO_LARGE9. Read PAYLOAD as LENGTH bytes.10. Read CRC16.11. Recompute CRC16 over: VERSION_FLAGS || LENGTH || PAYLOAD12. If computed CRC16 != stored CRC16: fail with BAD_CRC13. Ignore extracted bits after the parsed frame.14. Return PAYLOAD.A stricter application MAY reject trailing one bits after the parsed frame, but that behavior is not required for UGS-1 compatibility.If the caller expects text, decode PAYLOAD as UTF-8. If UTF-8 decoding fails, return INVALID_UTF8.12. Optional Scan ModeStrict mode is deterministic, but it fails if visible text appears before the embedded frame and that preceding text contains eligible characters.Scan mode searches for a valid frame at any extracted-bit offset.1. Extract all bits from the carrier text.2. For offset from 0 to bits.length - 64: if bits[offset : offset + 16] != MAGIC: continue Try to parse a frame beginning at offset. Before allocating payload storage: read LENGTH compute required_bits ensure required_bits <= bits.length - offset ensure LENGTH <= configured maximum payload size If version, flags, length, and CRC are valid: return the decoded payload and the bit offset3. If no valid frame is found: fail with NO_VALID_FRAMEBecause the frame uses both a 16-bit magic value and a 16-bit CRC, accidental false positives are unlikely in ordinary text. They are not impossible.Applications that need stronger false-positive resistance should use a larger checksum or authenticated payload wrapper.13. Capacity RulesFor profile H1:1 eligible character = 1 hidden bitRequired capacity:64 + 8 * payload_lengthExamples: Payload Payload bytes Required eligible characters empty payload 0 64 OK 2 80 hello 5 104 meet at 9 9 136 100-byte message 100 864 A practical encoder SHOULD report:capacity_bitsrequired_bitsunused_capacity_bitsmax_payload_bytesWhere:if capacity_bits < 64: max_payload_bytes = 0else: max_payload_bytes = floor((capacity_bits - 64) / 8)14. Worked Test Vector14.1 Hidden MessageOK14.2 Payload Bytes4F 4B14.3 Full Frame BytesAD 53 10 00 00 02 4F 4B 9E A914.4 Full Frame Bits10101101 01010011 00010000 00000000 0000000000000010 01001111 01001011 10011110 1010100114.5 Minimal Cover TextUse 80 Latin a characters:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaSince a is an eligible character, each a can encode one bit.14.6 Encoded Carrier as EscapesFor this test vector:bit 0 -> a U+0061bit 1 -> \\u0430 Cyrillic small аEncoded carrier, shown as escape groups:\\u0430a\\u0430a\\u0430\\u0430a\\u0430a\\u0430a\\u0430aa\\u0430\\u0430aaa\\u0430aaaaaaaaaaaaaaaaaaaaaaaaaa\\u0430aa\\u0430aa\\u0430\\u0430\\u0430\\u0430a\\u0430aa\\u0430a\\u0430\\u0430\\u0430aa\\u0430\\u0430\\u0430\\u0430a\\u0430a\\u0430a\\u0430aa\\u0430A correct decoder should recover:OK15. Error CodesImplementations SHOULD expose these distinct errors:INSUFFICIENT_CAPACITYNO_FRAMEBAD_MAGICUNSUPPORTED_VERSIONUNSUPPORTED_FLAGSINCOMPLETE_FRAMEPAYLOAD_TOO_LARGEBAD_CRCINVALID_UTF8NO_VALID_FRAMEFor privacy or simplicity, user-facing applications MAY collapse these into a generic result such as:no valid hidden message found16. Recommended API ShapeImplementations SHOULD expose byte-oriented primitives first:encode_bytes(cover_text, payload_bytes) -> carrier_textdecode_bytes(carrier_text, mode = \"strict\" | \"scan\") -> { payload_bytes, offset_bits optional}capacity(cover_text) -> { capacity_bits, max_payload_bytes}UTF-8 convenience wrappers MAY be provided:encode_text(cover_text, hidden_text) -> carrier_textdecode_text(carrier_text, mode = \"strict\" | \"scan\") -> hidden_textThe text wrappers MUST encode and decode payloads as UTF-8 without a byte-order mark.17. Optional Extension: Zero-Width Profile Z1Z1 is not part of mandatory UGS-1 H1 compatibility.It may be useful when cover text lacks enough homoglyph-capable characters.Unicode includes zero-width format characters such as:U+200B ZERO WIDTH SPACEU+200C ZERO WIDTH NON-JOINERU+200D ZERO WIDTH JOINERA simple Z1 profile could be:bit 0 -> U+200B ZERO WIDTH SPACEbit 1 -> U+200C ZERO WIDTH NON-JOINERA Z1 encoder would insert one zero-width character between visible code points.However, Z1 is often more fragile than H1 because messaging systems, editors, and security tools commonly strip invisible format characters.Variation selectors are another possible channel, but they are also fragile and can interact with rendering behavior.For a dependable first implementation, use H1.References:https://www.unicode.org/charts/nameslist/n_2000.htmlhttps://www.unicode.org/versions/Unicode16.0.0/core-spec/chapter-23/https://www.unicode.org/reports/tr37/18. Detector and SanitizerA companion detector can reveal or remove UGS-1 data.18.1 Reveal ModeFor every code point:if code point is a one variant: display it as [1:U+XXXX]else if code point is a zero variant: display it as [0:U+XXXX]else: display normallyReveal mode is useful for debugging, auditing, and teaching.18.2 Strip ModeFor every code point:if code point is a one variant: replace it with the corresponding zero variantelse: keep it unchangedStrip mode removes the H1 hidden channel while preserving the intended Latin visible text.This is useful defensively because mixed-script confusables are a known Unicode security concern.Reference: https://www.unicode.org/reports/tr39/19. Implementation ChecklistA conforming UGS-1 H1 implementation MUST:[ ] Use the mandatory H1 homoglyph table exactly.[ ] Operate on Unicode code points.[ ] Provide byte payload support.[ ] Encode text payloads as UTF-8 without BOM when using text wrappers.[ ] Build the exact frame format.[ ] Use MAGIC = 0xAD53.[ ] Use VERSION = 1.[ ] Use FLAGS = 0.[ ] Use 24-bit big-endian payload length.[ ] Use CRC-16/CCITT-FALSE.[ ] Encode bits MSB-first.[ ] Encode one bit per eligible character.[ ] Reset recognized one variants before embedding.[ ] Reject bad magic.[ ] Reject unsupported version.[ ] Reject unsupported flags.[ ] Reject incomplete frames.[ ] Reject oversized payloads according to implementation limits.[ ] Reject bad CRC.[ ] Avoid post-encoding normalization, transliteration, or sanitization.A robust implementation SHOULD also:[ ] Provide scan mode.[ ] Provide reveal mode.[ ] Provide strip mode.[ ] Report capacity before encoding.[ ] Avoid syntax-sensitive regions in structured text.[ ] Support a configurable maximum decode payload size.[ ] Clearly state that CRC16 is not authentication.20. Prior Art and Related Work — Informative20.1 Scope of This SectionUGS-1 does not claim novelty over the broad idea of hiding information in text by using Unicode look-alikes, invisible characters, or whitespace variants. Prior work exists in Unicode security, IDN homograph attacks, text watermarking, Unicode homoglyph substitution, Unicode space-character hiding, and zero-width-character steganography. The purpose of UGS-1 is narrower: it defines a small, deterministic, interoperable profile with a fixed homoglyph table, a byte-oriented frame, a length field, versioning, CRC validation, strict decoding, scan decoding, and explicit capacity/error behavior.This section is a non-exhaustive prior-art and related-work note, not a legal patent-clearance opinion.20.2 Unicode Visual Confusability and Homograph SecurityUnicode visual confusability is a well-documented security issue. Unicode Technical Report #36 describes visual spoofing as relying on different Unicode strings whose appearance in common fonts and screen sizes is close enough that users can mistake one for another. It also notes that Internationalized Domain Names increase opportunities for visual spoofing because the usable character repertoire is much larger than ASCII. (Unicode)Unicode Technical Standard #39 defines mechanisms for detecting visually confusable strings. It defines skeleton-based confusable detection, classifies confusables as single-script, mixed-script, or whole-script, and gives the canonical example of paypal versus pаypаl, where the second string contains U+0430 CYRILLIC SMALL LETTER A. (Unicode)The IDN homograph attack literature predates UGS-1 by decades. Gabrilovich and Gontmakher’s 2002 “The Homograph Attack” framed character resemblance as a security problem rather than merely a typographic nuisance, and discussed non-Latin substitutions that could make domain names appear authentic while resolving differently. Later measurement work on IDN homographs describes Unicode homoglyphs as visually similar characters that can be abused to create spoofing domains, and notes that Gabrilovich and Gontmakher demonstrated an IDN homograph using Russian letters in 2002. (arXiv)UGS-1 intentionally uses the same underlying property—different code points with similar glyphs—but for a framed steganographic/watermarking channel rather than for identifiers or domain-name spoofing. Implementations SHOULD NOT use UGS-1 inside security-sensitive identifiers such as domains, usernames, package names, certificates, executable filenames, payment addresses, or login prompts.20.3 Homoglyph-Based Text Watermarking and SteganographyAcademic work has already proposed Unicode homoglyph substitution for text watermarking. Rizzo, Bertini, and Montesi’s 2016 paper, “Content-preserving Text Watermarking through Unicode Homoglyph Substitution,” proposes a text watermarking technique based on substituting homoglyph characters for Latin symbols, using alternative Unicode symbols to preserve visual indistinguishability and text length. (ResearchGate)Follow-on work on fine-grain text watermarking uses homoglyph substitution for Latin symbols and whitespaces to protect small portions of text, while preserving visual indistinguishability and length. That work explicitly treats text watermarking as difficult because text has low embedding capacity and limited safe transformation space. (Manara)Hosmani, Bhat, and Chandrasekaran’s “Dual Stage Text Steganography Using Unicode Homoglyphs” is another direct related work. Its abstract describes a text steganography approach combining space manipulation, linguistic translation, and Unicode homoglyphs, implemented in Python. (ResearchGate)There are also practical implementations. The stegtext project describes hiding text inside text by replacing ASCII characters with visually similar Unicode homoglyphs. Its documentation gives the same basic bit model used by UGS-1: leaving an eligible character unchanged can represent 0, while swapping it with a visually identical homoglyph can represent 1; it also notes that characters with multiple homoglyphs can encode more than one bit. (GitHub)UGS-1 differs from these systems by deliberately choosing a conservative one-bit-per-character profile, a fixed mandatory table, a binary frame, a magic value, version and flags fields, a 24-bit payload length, CRC-16 validation, and specified decoder error behavior.20.4 Unicode Whitespace, Zero-Width, and Invisible-Character ChannelsUnicode text hiding is not limited to homoglyph substitution. UniSpaCh, published in 2012, uses Unicode space characters inserted into inter-word, inter-sentence, end-of-line, and paragraph spacing to encode external information in Microsoft Word documents, while aiming to improve imperceptibility and embedding efficiency. (ScienceDirect)More recent whitespace-replacement watermarking work similarly hides byte-encoded sequences in unformatted text by substituting conventional whitespace with visually similar Unicode spaces. The 2025 HICSS paper by Hellmeier, Qarawlus, Norkowski, and Howar reports a proof-of-concept multiplatform implementation and evaluates robustness, capacity, and visibility. (ResearchGate)Zero-width-character steganography is another established related family. The 330k Unicode steganography tool exposes text and binary encode/decode APIs and uses characters such as U+200C, U+200D, U+202C, and U+FEFF, while noting that U+200B may be deleted by Gmail in browser-sent mail. (330k) StegCloak is a JavaScript steganography tool that hides secrets inside text using special invisible Unicode characters, with optional compression, AES-256-CTR encryption, and HMAC integrity. (GitHub)UGS-1’s primary H1 profile is therefore best understood as a homoglyph profile, not a general Unicode steganography invention. The optional Z1 profile belongs to the older zero-width/invisible-character family and should be treated as more fragile in copy/paste, email, messaging, search indexing, normalization, and security-filtering pipelines.20.5 Normalization, Sanitization, and Defensive DetectionUnicode normalization is directly relevant to UGS-1 robustness. Unicode Standard Annex #15 defines normalization forms so equivalent strings can have unique binary representations; any process that normalizes, folds, transliterates, maps confusables, removes default-ignorable characters, or enforces a restricted character repertoire can alter or destroy a Unicode steganographic channel. (Unicode)Defensive systems can detect or neutralize UGS-1-like channels by using Unicode confusable data, skeleton mappings, mixed-script detection, or explicit canonicalization of known homoglyph pairs. Unicode Technical Standard #39 provides the standard basis for confusable detection and includes mappings such as Cyrillic small es to Latin c. (Unicode)A UGS-1 implementation SHOULD therefore include reveal and strip tooling. Reveal tooling helps auditors see code-point substitutions; strip tooling replaces UGS-1 one-variants with their Latin zero-variants, preserving visible text while removing the hidden channel.20.6 UGS-1 PositioningUGS-1 should be positioned as an interoperability profile for a known class of Unicode text steganography and watermarking techniques. It standardizes one conservative way to frame, embed, decode, validate, and strip a hidden byte payload using Unicode homoglyph variants.UGS-1 is not encryption. It does not provide confidentiality unless the payload is encrypted before embedding. It is also not robust against determined sanitization, paraphrasing, transliteration, OCR, Unicode confusable canonicalization, or manual replacement of suspicious non-Latin code points.Appropriate uses include controlled watermarking experiments, puzzles, protocol demonstrations, document-provenance research, educational security examples, and defensive testing. Inappropriate uses include spoofing identifiers, phishing, bypassing safety filters, hiding executable instructions, concealing policy-violating content, or impersonating trusted parties.20.7 Informative References[UTR36] Unicode Consortium, Unicode Technical Report #36: Unicode Security Considerations. Discusses visual spoofing, confusable strings, and IDN-related security risks. (Unicode)[UTS39] Unicode Consortium, Unicode Technical Standard #39: Unicode Security Mechanisms. Defines confusable detection, skeleton mappings, mixed-script confusables, and related data files. (Unicode)[UAX15] Unicode Consortium, Unicode Standard Annex #15: Unicode Normalization Forms. Defines normalization forms and explains how equivalent Unicode strings can be represented consistently. (Unicode)[Gabrilovich2002] Evgeniy Gabrilovich and Alex Gontmakher, The Homograph Attack, Communications of the ACM, 2002. Early security treatment of visually confusable characters in domain-name spoofing.[Rizzo2016] Stefano Giovanni Rizzo, Flavio Bertini, and Danilo Montesi, Content-preserving Text Watermarking through Unicode Homoglyph Substitution, IDEAS 2016. Proposes watermarking through Unicode homoglyph substitution for Latin symbols. (ResearchGate)[Rizzo2019] Rizzo et al., Fine-grain watermarking for intellectual property protection, EURASIP Journal on Information Security, 2019. Extends homoglyph/whitespace substitution for fine-grained document watermarking. (Manara)[Hosmani2015] Sachin Hosmani, H. G. Rama Bhat, and K. Chandrasekaran, Dual Stage Text Steganography Using Unicode Homoglyphs, 2015. Combines space manipulation, linguistic translation, and Unicode homoglyphs. (ResearchGate)[UniSpaCh2012] Lip Yee Por, Koksheik Wong, and Kok Onn Chee, UniSpaCh: A text-based data hiding method using Unicode space characters, Journal of Systems and Software, 2012. Uses Unicode space characters for text-based data hiding. (ScienceDirect)[Hellmeier2025] Hellmeier, Qarawlus, Norkowski, and Howar, A Hidden Digital Text Watermarking Method Using Unicode Whitespace Replacement, HICSS 2025. Replaces conventional whitespace with visually similar Unicode spaces to hide byte-encoded data. (ResearchGate)[stegtext] btimby/stegtext, practical Unicode homoglyph steganography implementation using ASCII-to-homoglyph character swaps. (GitHub)[StegCloak] KuroLabs/stegcloak, practical zero-width Unicode steganography implementation with compression, encryption, and integrity options. (GitHub)[330kUnicodeStego] 330k Unicode Steganography with Zero-Width Characters, browser-based zero-width text/binary encoder and decoder. (330k)", "content_html": "UGS-1 is a deterministic, low-bandwidth steganographic encoding for hiding a byte payload inside visible text by replacing selected Latin characters with visually similar Unicode characters.
UGS-1 is not encryption, authentication, or tamper protection. The CRC in this specification only detects accidental corruption. Anyone who understands the format can alter the payload and recompute the CRC.
If secrecy or tamper resistance is required, applications should encrypt and authenticate the payload before placing it in a UGS-1 frame, for example with an AEAD scheme.
UGS-1 data is fragile. Editors, messaging systems, source-control tools, spellcheckers, security gateways, LLM rewrites, transliteration tools, ASCII sanitizers, and confusable-character detectors may modify or remove the channel.
Unicode’s own security guidance discusses confusable characters and mechanisms for detecting them, so UGS-1 should be treated as a technique with security implications.
Reference: https://www.unicode.org/reports/tr39/
UGS-1 embeds a hidden byte payload inside visible text.
Conceptual example:
Latin a U+0061 encodes bit 0Cyrillic а U+0430 encodes bit 1Both glyphs may appear visually similar:
aBut they are different Unicode code points.
UGS-1 profile H1 encodes one bit per eligible visible character.
UGS-1 does not provide:
confidentialityauthenticationintegrity against deliberate tamperingplausible deniabilityrobust survival through arbitrary text processinghigh bandwidthUGS-1 is intended to be simple, deterministic, testable, and easy to detect or remove when needed.
Cover text
The visible text before embedding.
Carrier text
The visible text after embedding.
Payload
The hidden message as raw bytes.
Text payload
A payload interpreted as UTF-8 text.
Eligible character
A code point that appears in the UGS-1 H1 homoglyph table.
Zero variant
The ordinary Latin code point used to encode bit 0.
One variant
The visually similar Unicode code point used to encode bit 1.
Frame
The structured binary data embedded into the carrier text.
Variant reset
The process of replacing UGS-1 one variants with their corresponding zero variants before embedding. This is UGS-specific and must not be confused with Unicode normalization.
Implementations MUST operate on Unicode scalar values or code points, not encoded bytes.
Implementations MUST NOT iterate through UTF-16 strings in a way that incorrectly splits surrogate pairs. Profile H1 only uses BMP code points, but code-point handling keeps implementations portable.
Implementations MUST NOT normalize, case-fold, transliterate, ASCII-clean, confusable-map, or sanitize the carrier text after embedding.
Unicode normalization forms such as NFC, NFD, NFKC, and NFKD do not generally fold Cyrillic homoglyphs into Latin letters. However, other security and text-processing systems may do so. The larger practical risks are transliteration, ASCII filtering, confusable-skeleton mapping, spellcheck, OCR, LLM rewriting, and security sanitization.
Implementations SHOULD test the intended transport channel before use.
Reference: https://www.unicode.org/reports/tr15/
Applications SHOULD avoid embedding into syntax-sensitive regions, including:
URLsemail addressesdomain namessource codeidentifiersHTML tags and attributesMarkdown syntaxJSON keysYAML keysCSV headersshell commandsdatabase queriesfilenamescryptographic materialFor HTML, XML, Markdown, or rich-text formats, applications SHOULD embed only in visible prose text nodes, not in markup or syntax.
Replacing Latin letters with homoglyphs can preserve visual appearance while changing program behavior.
UGS-1 H1 encodes one bit per eligible character.
bit 0 -> use the Latin zero variantbit 1 -> use the homoglyph one variantAll UGS-1 H1 implementations MUST support this exact table.
| Bit 0 Latin | Code point | Bit 1 homoglyph | Code point | Bit-1 character name |
|---|---|---|---|---|
A | U+0041 | А | U+0410 | Cyrillic Capital Letter A |
a | U+0061 | а | U+0430 | Cyrillic Small Letter A |
B | U+0042 | В | U+0412 | Cyrillic Capital Letter Ve |
C | U+0043 | С | U+0421 | Cyrillic Capital Letter Es |
c | U+0063 | с | U+0441 | Cyrillic Small Letter Es |
E | U+0045 | Е | U+0415 | Cyrillic Capital Letter Ie |
e | U+0065 | е | U+0435 | Cyrillic Small Letter Ie |
H | U+0048 | Н | U+041D | Cyrillic Capital Letter En |
I | U+0049 | І | U+0406 | Cyrillic Capital Letter Byelorussian-Ukrainian I |
i | U+0069 | і | U+0456 | Cyrillic Small Letter Byelorussian-Ukrainian I |
J | U+004A | Ј | U+0408 | Cyrillic Capital Letter Je |
j | U+006A | ј | U+0458 | Cyrillic Small Letter Je |
K | U+004B | К | U+041A | Cyrillic Capital Letter Ka |
M | U+004D | М | U+041C | Cyrillic Capital Letter Em |
O | U+004F | О | U+041E | Cyrillic Capital Letter O |
o | U+006F | о | U+043E | Cyrillic Small Letter O |
P | U+0050 | Р | U+0420 | Cyrillic Capital Letter Er |
p | U+0070 | р | U+0440 | Cyrillic Small Letter Er |
T | U+0054 | Т | U+0422 | Cyrillic Capital Letter Te |
X | U+0058 | Х | U+0425 | Cyrillic Capital Letter Ha |
x | U+0078 | х | U+0445 | Cyrillic Small Letter Ha |
y | U+0079 | у | U+0443 | Cyrillic Small Letter U |
This table intentionally avoids many tempting lookalikes that are more font-dependent.
The payload is wrapped in a binary frame.
All multi-bit fields are encoded most-significant bit first.
All multi-byte integers are encoded big-endian.
MAGIC 16 bitsVERSION 4 bitsFLAGS 4 bitsLENGTH 24 bitsPAYLOAD 8 * LENGTH bitsCRC16 16 bitsTotal overhead:
64 bitsRequired capacity:
required_bits = 64 + 8 * payload_length_in_bytesFixed value:
0xAD53Binary:
10101101 01010011For this specification:
0x1Encoded as 4 bits:
0001For this specification:
0x0Encoded as 4 bits:
0000All nonzero flag values are reserved.
A decoder MUST reject frames with unknown nonzero flags unless explicitly configured to support an extension.
LENGTH is a 24-bit unsigned integer.
It gives the number of payload bytes.
Maximum representable payload size:
16,777,215 bytesPractical payload size is usually much smaller because the cover text must contain enough eligible characters.
Decoders SHOULD support a configurable maximum accepted payload size.
The payload is raw bytes.
For ordinary text messages, the payload MUST be UTF-8 encoded text without a byte-order mark.
CRC-16/CCITT-FALSE is computed over:
VERSION_FLAGS || LENGTH || PAYLOADWhere:
VERSION_FLAGS = one byte: high nibble VERSION, low nibble FLAGSFor UGS-1 v1 with flags 0:
VERSION_FLAGS = 0x10CRC parameters:
Name: CRC-16/CCITT-FALSEWidth: 16Polynomial: 0x1021Initial: 0xFFFFRefIn: falseRefOut: falseXorOut: 0x0000Output: big-endianNormative pseudocode:
function crc16_ccitt_false(bytes): crc = 0xFFFF for b in bytes: crc = crc XOR (b << 8) repeat 8 times: if (crc AND 0x8000) != 0: crc = ((crc << 1) XOR 0x1021) AND 0xFFFF else: crc = (crc << 1) AND 0xFFFF return crcFor a text message:
payload_bytes = UTF8_ENCODE(hidden_message)Then construct:
version_flags = 0x10length = 24-bit big-endian byte lengthcrc_input = version_flags || length || payload_bytescrc = CRC16_CCITT_FALSE(crc_input)frame_bytes = 0xAD 0x53 || version_flags || length || payload_bytes || crcframe_bits = frame_bytes as bits, MSB firstExample hidden message:
OKUTF-8 payload bytes:
4F 4BFrame bytes:
AD 53 10 00 00 02 4F 4B 9E A9Frame bits:
10101101 01010011 00010000 00000000 0000000000000010 01001111 01001011 10011110 10101001Input:
cover_textpayload_bytesOutput:
carrier_textAlgorithm:
1. Build the UGS-1 frame.2. Convert frame bytes to frame bits, MSB first.3. Reset UGS-1 variants in the cover text: For every code point: if it is a one variant from the H1 table: replace it with its corresponding zero variant else: leave it unchanged4. Count capacity: capacity_bits = number of code points in the reset cover text that are zero variants in the H1 table5. If capacity_bits < frame_bits.length: fail with INSUFFICIENT_CAPACITY6. Initialize bit_index = 0.7. For each code point cp in the reset cover text: if cp is not a zero variant in the H1 table: output cp continue if bit_index >= frame_bits.length: output cp continue bit = frame_bits[bit_index] if bit == 0: output cp if bit == 1: output corresponding one variant bit_index = bit_index + 18. Return the output text.The encoder MUST NOT alter non-eligible characters except when resetting recognized one variants to their corresponding zero variants.
The encoder SHOULD reset variants before embedding so that accidental pre-existing homoglyphs do not become hidden bits.
Input:
carrier_textOutput:
payload_bytes1. Initialize bits = empty list.2. For each code point cp in carrier_text: if cp is a zero variant in the H1 table: append bit 0 to bits else if cp is a one variant in the H1 table: append bit 1 to bits else: ignore cpStrict mode assumes the frame starts at the first extracted bit.
1. If bits.length < 64: fail with NO_FRAME2. Read first 16 bits as MAGIC. If MAGIC != 0xAD53: fail with BAD_MAGIC3. Read next 4 bits as VERSION. If VERSION != 1: fail with UNSUPPORTED_VERSION4. Read next 4 bits as FLAGS. If FLAGS != 0: fail with UNSUPPORTED_FLAGS5. Read next 24 bits as LENGTH.6. required_bits = 64 + 8 * LENGTH7. If required_bits > bits.length: fail with INCOMPLETE_FRAME8. If LENGTH exceeds the implementation's configured maximum payload size: fail with PAYLOAD_TOO_LARGE9. Read PAYLOAD as LENGTH bytes.10. Read CRC16.11. Recompute CRC16 over: VERSION_FLAGS || LENGTH || PAYLOAD12. If computed CRC16 != stored CRC16: fail with BAD_CRC13. Ignore extracted bits after the parsed frame.14. Return PAYLOAD.A stricter application MAY reject trailing one bits after the parsed frame, but that behavior is not required for UGS-1 compatibility.
If the caller expects text, decode PAYLOAD as UTF-8. If UTF-8 decoding fails, return INVALID_UTF8.
Strict mode is deterministic, but it fails if visible text appears before the embedded frame and that preceding text contains eligible characters.
Scan mode searches for a valid frame at any extracted-bit offset.
1. Extract all bits from the carrier text.2. For offset from 0 to bits.length - 64: if bits[offset : offset + 16] != MAGIC: continue Try to parse a frame beginning at offset. Before allocating payload storage: read LENGTH compute required_bits ensure required_bits <= bits.length - offset ensure LENGTH <= configured maximum payload size If version, flags, length, and CRC are valid: return the decoded payload and the bit offset3. If no valid frame is found: fail with NO_VALID_FRAMEBecause the frame uses both a 16-bit magic value and a 16-bit CRC, accidental false positives are unlikely in ordinary text. They are not impossible.
Applications that need stronger false-positive resistance should use a larger checksum or authenticated payload wrapper.
For profile H1:
1 eligible character = 1 hidden bitRequired capacity:
64 + 8 * payload_lengthExamples:
| Payload | Payload bytes | Required eligible characters |
|---|---|---|
| empty payload | 0 | 64 |
OK | 2 | 80 |
hello | 5 | 104 |
meet at 9 | 9 | 136 |
| 100-byte message | 100 | 864 |
A practical encoder SHOULD report:
capacity_bitsrequired_bitsunused_capacity_bitsmax_payload_bytesWhere:
if capacity_bits < 64: max_payload_bytes = 0else: max_payload_bytes = floor((capacity_bits - 64) / 8)OK4F 4BAD 53 10 00 00 02 4F 4B 9E A910101101 01010011 00010000 00000000 0000000000000010 01001111 01001011 10011110 10101001Use 80 Latin a characters:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaSince a is an eligible character, each a can encode one bit.
For this test vector:
bit 0 -> a U+0061bit 1 -> \\u0430 Cyrillic small аEncoded carrier, shown as escape groups:
\\u0430a\\u0430a\\u0430\\u0430a\\u0430a\\u0430a\\u0430aa\\u0430\\u0430aaa\\u0430aaaaaaaaaaaaaaaaaaaaaaaaaa\\u0430aa\\u0430aa\\u0430\\u0430\\u0430\\u0430a\\u0430aa\\u0430a\\u0430\\u0430\\u0430aa\\u0430\\u0430\\u0430\\u0430a\\u0430a\\u0430a\\u0430aa\\u0430A correct decoder should recover:
OKImplementations SHOULD expose these distinct errors:
INSUFFICIENT_CAPACITYNO_FRAMEBAD_MAGICUNSUPPORTED_VERSIONUNSUPPORTED_FLAGSINCOMPLETE_FRAMEPAYLOAD_TOO_LARGEBAD_CRCINVALID_UTF8NO_VALID_FRAMEFor privacy or simplicity, user-facing applications MAY collapse these into a generic result such as:
no valid hidden message foundImplementations SHOULD expose byte-oriented primitives first:
encode_bytes(cover_text, payload_bytes) -> carrier_textdecode_bytes(carrier_text, mode = \"strict\" | \"scan\") -> { payload_bytes, offset_bits optional}capacity(cover_text) -> { capacity_bits, max_payload_bytes}UTF-8 convenience wrappers MAY be provided:
encode_text(cover_text, hidden_text) -> carrier_textdecode_text(carrier_text, mode = \"strict\" | \"scan\") -> hidden_textThe text wrappers MUST encode and decode payloads as UTF-8 without a byte-order mark.
Z1 is not part of mandatory UGS-1 H1 compatibility.
It may be useful when cover text lacks enough homoglyph-capable characters.
Unicode includes zero-width format characters such as:
U+200B ZERO WIDTH SPACEU+200C ZERO WIDTH NON-JOINERU+200D ZERO WIDTH JOINERA simple Z1 profile could be:
bit 0 -> U+200B ZERO WIDTH SPACEbit 1 -> U+200C ZERO WIDTH NON-JOINERA Z1 encoder would insert one zero-width character between visible code points.
However, Z1 is often more fragile than H1 because messaging systems, editors, and security tools commonly strip invisible format characters.
Variation selectors are another possible channel, but they are also fragile and can interact with rendering behavior.
For a dependable first implementation, use H1.
References:
https://www.unicode.org/charts/nameslist/n_2000.htmlhttps://www.unicode.org/versions/Unicode16.0.0/core-spec/chapter-23/https://www.unicode.org/reports/tr37/A companion detector can reveal or remove UGS-1 data.
For every code point:
if code point is a one variant: display it as [1:U+XXXX]else if code point is a zero variant: display it as [0:U+XXXX]else: display normallyReveal mode is useful for debugging, auditing, and teaching.
For every code point:
if code point is a one variant: replace it with the corresponding zero variantelse: keep it unchangedStrip mode removes the H1 hidden channel while preserving the intended Latin visible text.
This is useful defensively because mixed-script confusables are a known Unicode security concern.
Reference: https://www.unicode.org/reports/tr39/
A conforming UGS-1 H1 implementation MUST:
[ ] Use the mandatory H1 homoglyph table exactly.[ ] Operate on Unicode code points.[ ] Provide byte payload support.[ ] Encode text payloads as UTF-8 without BOM when using text wrappers.[ ] Build the exact frame format.[ ] Use MAGIC = 0xAD53.[ ] Use VERSION = 1.[ ] Use FLAGS = 0.[ ] Use 24-bit big-endian payload length.[ ] Use CRC-16/CCITT-FALSE.[ ] Encode bits MSB-first.[ ] Encode one bit per eligible character.[ ] Reset recognized one variants before embedding.[ ] Reject bad magic.[ ] Reject unsupported version.[ ] Reject unsupported flags.[ ] Reject incomplete frames.[ ] Reject oversized payloads according to implementation limits.[ ] Reject bad CRC.[ ] Avoid post-encoding normalization, transliteration, or sanitization.A robust implementation SHOULD also:
[ ] Provide scan mode.[ ] Provide reveal mode.[ ] Provide strip mode.[ ] Report capacity before encoding.[ ] Avoid syntax-sensitive regions in structured text.[ ] Support a configurable maximum decode payload size.[ ] Clearly state that CRC16 is not authentication.UGS-1 does not claim novelty over the broad idea of hiding information in text by using Unicode look-alikes, invisible characters, or whitespace variants. Prior work exists in Unicode security, IDN homograph attacks, text watermarking, Unicode homoglyph substitution, Unicode space-character hiding, and zero-width-character steganography. The purpose of UGS-1 is narrower: it defines a small, deterministic, interoperable profile with a fixed homoglyph table, a byte-oriented frame, a length field, versioning, CRC validation, strict decoding, scan decoding, and explicit capacity/error behavior.
This section is a non-exhaustive prior-art and related-work note, not a legal patent-clearance opinion.
Unicode visual confusability is a well-documented security issue. Unicode Technical Report #36 describes visual spoofing as relying on different Unicode strings whose appearance in common fonts and screen sizes is close enough that users can mistake one for another. It also notes that Internationalized Domain Names increase opportunities for visual spoofing because the usable character repertoire is much larger than ASCII. (Unicode)
Unicode Technical Standard #39 defines mechanisms for detecting visually confusable strings. It defines skeleton-based confusable detection, classifies confusables as single-script, mixed-script, or whole-script, and gives the canonical example of paypal versus pаypаl, where the second string contains U+0430 CYRILLIC SMALL LETTER A. (Unicode)
The IDN homograph attack literature predates UGS-1 by decades. Gabrilovich and Gontmakher’s 2002 “The Homograph Attack” framed character resemblance as a security problem rather than merely a typographic nuisance, and discussed non-Latin substitutions that could make domain names appear authentic while resolving differently. Later measurement work on IDN homographs describes Unicode homoglyphs as visually similar characters that can be abused to create spoofing domains, and notes that Gabrilovich and Gontmakher demonstrated an IDN homograph using Russian letters in 2002. (arXiv)
UGS-1 intentionally uses the same underlying property—different code points with similar glyphs—but for a framed steganographic/watermarking channel rather than for identifiers or domain-name spoofing. Implementations SHOULD NOT use UGS-1 inside security-sensitive identifiers such as domains, usernames, package names, certificates, executable filenames, payment addresses, or login prompts.
Academic work has already proposed Unicode homoglyph substitution for text watermarking. Rizzo, Bertini, and Montesi’s 2016 paper, “Content-preserving Text Watermarking through Unicode Homoglyph Substitution,” proposes a text watermarking technique based on substituting homoglyph characters for Latin symbols, using alternative Unicode symbols to preserve visual indistinguishability and text length. (ResearchGate)
Follow-on work on fine-grain text watermarking uses homoglyph substitution for Latin symbols and whitespaces to protect small portions of text, while preserving visual indistinguishability and length. That work explicitly treats text watermarking as difficult because text has low embedding capacity and limited safe transformation space. (Manara)
Hosmani, Bhat, and Chandrasekaran’s “Dual Stage Text Steganography Using Unicode Homoglyphs” is another direct related work. Its abstract describes a text steganography approach combining space manipulation, linguistic translation, and Unicode homoglyphs, implemented in Python. (ResearchGate)
There are also practical implementations. The stegtext project describes hiding text inside text by replacing ASCII characters with visually similar Unicode homoglyphs. Its documentation gives the same basic bit model used by UGS-1: leaving an eligible character unchanged can represent 0, while swapping it with a visually identical homoglyph can represent 1; it also notes that characters with multiple homoglyphs can encode more than one bit. (GitHub)
UGS-1 differs from these systems by deliberately choosing a conservative one-bit-per-character profile, a fixed mandatory table, a binary frame, a magic value, version and flags fields, a 24-bit payload length, CRC-16 validation, and specified decoder error behavior.
Unicode text hiding is not limited to homoglyph substitution. UniSpaCh, published in 2012, uses Unicode space characters inserted into inter-word, inter-sentence, end-of-line, and paragraph spacing to encode external information in Microsoft Word documents, while aiming to improve imperceptibility and embedding efficiency. (ScienceDirect)
More recent whitespace-replacement watermarking work similarly hides byte-encoded sequences in unformatted text by substituting conventional whitespace with visually similar Unicode spaces. The 2025 HICSS paper by Hellmeier, Qarawlus, Norkowski, and Howar reports a proof-of-concept multiplatform implementation and evaluates robustness, capacity, and visibility. (ResearchGate)
Zero-width-character steganography is another established related family. The 330k Unicode steganography tool exposes text and binary encode/decode APIs and uses characters such as U+200C, U+200D, U+202C, and U+FEFF, while noting that U+200B may be deleted by Gmail in browser-sent mail. (330k) StegCloak is a JavaScript steganography tool that hides secrets inside text using special invisible Unicode characters, with optional compression, AES-256-CTR encryption, and HMAC integrity. (GitHub)
UGS-1’s primary H1 profile is therefore best understood as a homoglyph profile, not a general Unicode steganography invention. The optional Z1 profile belongs to the older zero-width/invisible-character family and should be treated as more fragile in copy/paste, email, messaging, search indexing, normalization, and security-filtering pipelines.
Unicode normalization is directly relevant to UGS-1 robustness. Unicode Standard Annex #15 defines normalization forms so equivalent strings can have unique binary representations; any process that normalizes, folds, transliterates, maps confusables, removes default-ignorable characters, or enforces a restricted character repertoire can alter or destroy a Unicode steganographic channel. (Unicode)
Defensive systems can detect or neutralize UGS-1-like channels by using Unicode confusable data, skeleton mappings, mixed-script detection, or explicit canonicalization of known homoglyph pairs. Unicode Technical Standard #39 provides the standard basis for confusable detection and includes mappings such as Cyrillic small es to Latin c. (Unicode)
A UGS-1 implementation SHOULD therefore include reveal and strip tooling. Reveal tooling helps auditors see code-point substitutions; strip tooling replaces UGS-1 one-variants with their Latin zero-variants, preserving visible text while removing the hidden channel.
UGS-1 should be positioned as an interoperability profile for a known class of Unicode text steganography and watermarking techniques. It standardizes one conservative way to frame, embed, decode, validate, and strip a hidden byte payload using Unicode homoglyph variants.
UGS-1 is not encryption. It does not provide confidentiality unless the payload is encrypted before embedding. It is also not robust against determined sanitization, paraphrasing, transliteration, OCR, Unicode confusable canonicalization, or manual replacement of suspicious non-Latin code points.
Appropriate uses include controlled watermarking experiments, puzzles, protocol demonstrations, document-provenance research, educational security examples, and defensive testing. Inappropriate uses include spoofing identifiers, phishing, bypassing safety filters, hiding executable instructions, concealing policy-violating content, or impersonating trusted parties.
[UTR36] Unicode Consortium, Unicode Technical Report #36: Unicode Security Considerations. Discusses visual spoofing, confusable strings, and IDN-related security risks. (Unicode)
[UTS39] Unicode Consortium, Unicode Technical Standard #39: Unicode Security Mechanisms. Defines confusable detection, skeleton mappings, mixed-script confusables, and related data files. (Unicode)
[UAX15] Unicode Consortium, Unicode Standard Annex #15: Unicode Normalization Forms. Defines normalization forms and explains how equivalent Unicode strings can be represented consistently. (Unicode)
[Gabrilovich2002] Evgeniy Gabrilovich and Alex Gontmakher, The Homograph Attack, Communications of the ACM, 2002. Early security treatment of visually confusable characters in domain-name spoofing.
[Rizzo2016] Stefano Giovanni Rizzo, Flavio Bertini, and Danilo Montesi, Content-preserving Text Watermarking through Unicode Homoglyph Substitution, IDEAS 2016. Proposes watermarking through Unicode homoglyph substitution for Latin symbols. (ResearchGate)
[Rizzo2019] Rizzo et al., Fine-grain watermarking for intellectual property protection, EURASIP Journal on Information Security, 2019. Extends homoglyph/whitespace substitution for fine-grained document watermarking. (Manara)
[Hosmani2015] Sachin Hosmani, H. G. Rama Bhat, and K. Chandrasekaran, Dual Stage Text Steganography Using Unicode Homoglyphs, 2015. Combines space manipulation, linguistic translation, and Unicode homoglyphs. (ResearchGate)
[UniSpaCh2012] Lip Yee Por, Koksheik Wong, and Kok Onn Chee, UniSpaCh: A text-based data hiding method using Unicode space characters, Journal of Systems and Software, 2012. Uses Unicode space characters for text-based data hiding. (ScienceDirect)
[Hellmeier2025] Hellmeier, Qarawlus, Norkowski, and Howar, A Hidden Digital Text Watermarking Method Using Unicode Whitespace Replacement, HICSS 2025. Replaces conventional whitespace with visually similar Unicode spaces to hide byte-encoded data. (ResearchGate)
[stegtext] btimby/stegtext, practical Unicode homoglyph steganography implementation using ASCII-to-homoglyph character swaps. (GitHub)
[StegCloak] KuroLabs/stegcloak, practical zero-width Unicode steganography implementation with compression, encryption, and integrity options. (GitHub)
[330kUnicodeStego] 330k Unicode Steganography with Zero-Width Characters, browser-based zero-width text/binary encoder and decoder. (330k)
", "url": "https://tedt.org/UGS-1-Unicode-Glyph-Variant-Steganography/", "image": "/img/2026-07/UGS-1.webp", "tags": ["unicode","steganography","homoglyphs","confusables","text encoding","security","specifications","crc16"], "date_published": "2026-07-04T00:00:00-07:00", "date_modified": "2026-07-04T00:00:00-07:00","author":{"avatar":"https://secure.gravatar.com/avatar/a76b4d6291cecb3a738896a971bfb903?s=512&d=mp&r=g","name":"Ted Tschopp","url":"https://tedt.org/"}}, { "id": "https://tedt.org/The-Backlog-Doesnt-Blink/", "title": "The Backlog Doesn't Blink", "summary": "A tense, emotionally grounded hip-hop musical-theater song lyric about IT delivery teams, backlog pressure, risk, compliance, legacy systems, QA, security, and the human load behind every queue.", "content_text": "The Backlog Doesn’t Blink is a tense, emotionally grounded musical-theater response number for the IT Delivery Team. The music should feel like pressure accumulating: steady kick, clipped hi-hats, low piano pulses, orchestral stabs, and subtle machine-room textures.Vocals begin controlled and procedural, almost like ticket intake language, then grow more human and urgent as the team reveals the weight behind the queue. Different IT roles trade sharp rap verses: delivery, integration, compliance, security, QA, legacy, and product ownership.The chorus should be heavy, memorable, and weary, showing that the backlog is not just work. It is emotional load, risk, and responsibility. The song should not sound defensive so much as exhausted, dignified, and honest: IT is not blocking the future; it is trying to keep the whole enterprise from breaking.LyricsAct I, Song 5 - The Backlog Doesn’t BlinkIT Delivery Team, whispered rhythmRequest received.Priority high.Business critical.Reason why.Request received.Promise due.Everything urgent.Everything true.Delivery LeadYou think we don’t see it?We see every line.Every “need by Monday,”every “running out of time.”Every ticket is a person,every person has a name,every name has a customerwaiting in the flame.We are not sleeping.We are not slow.We are not laughingwhile the red lights glow.We are buried in the asks,buried in the risk,trying to keep the whole worldfrom falling off the disk.IT EnsembleThe backlog doesn’t blink.The backlog doesn’t breathe.It just sits there countingwhat everybody needs.Systems AnalystThis one needs a workflow.This one needs a feed.This one needs a dashboardfor a newly urgent need.This one touches payroll.This one touches claims.This one says “just simple,”then lists twelve system names.Integration EngineerNothing is “just connect it”when the old code runs the floor.There’s a vendor with a tunnelthrough a contract from before.There’s a file drop at midnight,there’s a batch job on a chain,there’s an API that smileswhen the test data behaves.Compliance AnalystBefore we move the data,we have questions to pursue:Who approved the purpose?What are we allowed to do?What region? What retention?What consent? What audit trail?One missing answerand the whole thing fails.Security ReviewerA role is not a rumor.A token is not trust.You want the door to open?Then the key must know it must.I am not the thundercloudthat came to kill your spark.I am the person askingwhat can happen in the dark.Chorus - IT Delivery TeamThe backlog doesn’t blink.It doesn’t care who’s tired.It doesn’t see the meetingsor the bridges held by wires.It doesn’t hear “we’re trying.”It doesn’t feel the strain.It only keeps on growinglike a river in the rain.We are not the wall.We are not the curse.We are holding ten tomorrowsin a system built for worse.If you built around the wait,we know how it came to this.But every gap becomes a roadwhen the backlog doesn’t blink.Legacy EngineerYou call it legacy.I call it still alive.It runs the orders, pays the claims,keeps the core machine at five.It has comments with no authors,tables older than the cloud,one retired consultantwho remembers half out loud.So yes, I move carefully.Yes, I test twice.Because a “small enhancement”can have enterprise price.QA LeadYou want speed? So do we.You want less delay? Same.But if it ships with hidden cracks,who carries the blame?A happy path demois a song in the sun.But the rain has requirements,and the edge cases run.Product OwnerI’ve got leaders asking,“Can we make it all fit?”With three teams and a roadmapand a budget cut split.I’ve got ten number-onesin a single ranked list.Everybody says, “Mine first.”Everybody says, “Risk.”Business Voices, overlappingNeed it for the quarter!Need it for the client!Need it for compliance!Need the system silent!Need it for the region!Need it for the board!Need it by tomorrow!Can you please do more?IT Ensemble, risingWe do more.We stretch thin.We patch doorswhile the flood comes in.We plan releases,we guard the core,we say “not yet”and you hear “no more.”But “not yet” is not neglect.“Review” is not disdain.Sometimes the slowest-looking handis holding back the rain.Bridge - Delivery LeadAnd yes, we know the shadow grewwhere the light could not arrive.We know you built the workaroundbecause the need was still alive.We know the queue made strangersof the people we should know.We know a ticket numberis a terrible place to go.So don’t hide the spark from us.Don’t build alone in blue.Bring the pain before the fixbecomes another hidden truth.Citizen Builder, entering quietlyI thought you didn’t care.Delivery LeadWe cared and had no room.Citizen BuilderI thought the process froze.Systems AnalystIt did.Under too much “soon.”Citizen BuilderThen what are we supposed to do?IT Delivery TeamBuild with us before it spreads.Name the risk before it threads.Show the need before the patch.Let us help you make it last.Final Chorus - Full IT Delivery TeamThe backlog doesn’t blink.It doesn’t pause for pain.It doesn’t see the human handsthat hold the moving train.But we are still here building,still here counting cost,still here finding pathwaysthrough the systems we inherited and lost.We are not the wall.We are not the chain.We are maps inside the thunder,we are shelter in the rain.If the world is self-creating,then the old ways have to shift.Bring the builders to the backlog.Bring more IT in IT.Outro - IT Ensemble, softRequest received.Priority high.", "content_html": "The Backlog Doesn’t Blink is a tense, emotionally grounded musical-theater response number for the IT Delivery Team. The music should feel like pressure accumulating: steady kick, clipped hi-hats, low piano pulses, orchestral stabs, and subtle machine-room textures.
Vocals begin controlled and procedural, almost like ticket intake language, then grow more human and urgent as the team reveals the weight behind the queue. Different IT roles trade sharp rap verses: delivery, integration, compliance, security, QA, legacy, and product ownership.
The chorus should be heavy, memorable, and weary, showing that the backlog is not just work. It is emotional load, risk, and responsibility. The song should not sound defensive so much as exhausted, dignified, and honest: IT is not blocking the future; it is trying to keep the whole enterprise from breaking.
Request received.
Priority high.
Business critical.
Reason why.
Request received.
Promise due.
Everything urgent.
Everything true.
You think we don’t see it?
We see every line.
Every “need by Monday,”
every “running out of time.”
Every ticket is a person,
every person has a name,
every name has a customer
waiting in the flame.
We are not sleeping.
We are not slow.
We are not laughing
while the red lights glow.
We are buried in the asks,
buried in the risk,
trying to keep the whole world
from falling off the disk.
The backlog doesn’t blink.
The backlog doesn’t breathe.
It just sits there counting
what everybody needs.
This one needs a workflow.
This one needs a feed.
This one needs a dashboard
for a newly urgent need.
This one touches payroll.
This one touches claims.
This one says “just simple,”
then lists twelve system names.
Nothing is “just connect it”
when the old code runs the floor.
There’s a vendor with a tunnel
through a contract from before.
There’s a file drop at midnight,
there’s a batch job on a chain,
there’s an API that smiles
when the test data behaves.
Before we move the data,
we have questions to pursue:
Who approved the purpose?
What are we allowed to do?
What region? What retention?
What consent? What audit trail?
One missing answer
and the whole thing fails.
A role is not a rumor.
A token is not trust.
You want the door to open?
Then the key must know it must.
I am not the thundercloud
that came to kill your spark.
I am the person asking
what can happen in the dark.
The backlog doesn’t blink.
It doesn’t care who’s tired.
It doesn’t see the meetings
or the bridges held by wires.
It doesn’t hear “we’re trying.”
It doesn’t feel the strain.
It only keeps on growing
like a river in the rain.
We are not the wall.
We are not the curse.
We are holding ten tomorrows
in a system built for worse.
If you built around the wait,
we know how it came to this.
But every gap becomes a road
when the backlog doesn’t blink.
You call it legacy.
I call it still alive.
It runs the orders, pays the claims,
keeps the core machine at five.
It has comments with no authors,
tables older than the cloud,
one retired consultant
who remembers half out loud.
So yes, I move carefully.
Yes, I test twice.
Because a “small enhancement”
can have enterprise price.
You want speed? So do we.
You want less delay? Same.
But if it ships with hidden cracks,
who carries the blame?
A happy path demo
is a song in the sun.
But the rain has requirements,
and the edge cases run.
I’ve got leaders asking,
“Can we make it all fit?”
With three teams and a roadmap
and a budget cut split.
I’ve got ten number-ones
in a single ranked list.
Everybody says, “Mine first.”
Everybody says, “Risk.”
Need it for the quarter!
Need it for the client!
Need it for compliance!
Need the system silent!
Need it for the region!
Need it for the board!
Need it by tomorrow!
Can you please do more?
We do more.
We stretch thin.
We patch doors
while the flood comes in.
We plan releases,
we guard the core,
we say “not yet”
and you hear “no more.”
But “not yet” is not neglect.
“Review” is not disdain.
Sometimes the slowest-looking hand
is holding back the rain.
And yes, we know the shadow grew
where the light could not arrive.
We know you built the workaround
because the need was still alive.
We know the queue made strangers
of the people we should know.
We know a ticket number
is a terrible place to go.
So don’t hide the spark from us.
Don’t build alone in blue.
Bring the pain before the fix
becomes another hidden truth.
I thought you didn’t care.
We cared and had no room.
I thought the process froze.
It did.
Under too much “soon.”
Then what are we supposed to do?
Build with us before it spreads.
Name the risk before it threads.
Show the need before the patch.
Let us help you make it last.
The backlog doesn’t blink.
It doesn’t pause for pain.
It doesn’t see the human hands
that hold the moving train.
But we are still here building,
still here counting cost,
still here finding pathways
through the systems we inherited and lost.
We are not the wall.
We are not the chain.
We are maps inside the thunder,
we are shelter in the rain.
If the world is self-creating,
then the old ways have to shift.
Bring the builders to the backlog.
Bring more IT in IT.
Request received.
Priority high.
Shadow App Serenade is a sly, syncopated hip-hop musical-theater number with a playful surface and a nervous pulse underneath. The groove should feel like a secret being passed between desks: light percussion, plucked bass, muted piano, finger snaps, soft synth ticks, and tiny digital blips that mimic hidden automations running in the background.
The Citizen Builders Ensemble sings and raps in quick, conspiratorial phrases, trading lines like office gossip with a wink. The chorus should be catchy and almost charming, but each reprise grows darker as the audience realizes these little fixes are now business-critical.
Vocals move from playful whispers to layered, uneasy harmonies. By the end, the song has turned the clever workaround into an operating model question. The final silence lands because IT asks the thing every production system eventually asks: who supports it?
Shh.
Don’t name it.
Don’t claim it.
Don’t put it on a slide.
Shh.
Don’t frame it.
Don’t blame it.
It’s just helping on the side.
I got a spreadsheet in a folder
called “Archive_Do_Not_Delete,”
and every Friday morning
it tells Finance what to meet.
I got a form behind a form
behind a calendar invite.
It routes twelve approvals
while the workflow sleeps at night.
I got a bot with no badge,
no desk, no name, no chair,
but when the orders start to wobble,
guess who’s always there?
It’s a little fix, a little flow,
a little “nobody needs to know,”
a little button, little sheet,
little miracle on repeat.
This is our shadow app serenade,
the tune that the official roadmap never played.
Tiny tools in the dark, keeping promises made,
tap, tap, humming in the shade.
It’s a shadow app serenade,
not quite blessed and not quite afraid.
When the big machine stalls and the bright plans fade,
we keep the company running with a shadow app serenade.
Mine started as a tracker
for a problem in the queue.
Then my manager said, “Perfect,
can Region Two use it too?”
Mine was just a dashboard
with a graph that made us proud.
Now executives quote it
like it came down from a cloud.
Mine sends one little email
when the numbers don’t align.
Now Legal reads the copy
and Support lives by the line.
Copy this tab, don’t touch row three.
Password’s in a note from Marie.
If Marie leaves, we improvise.
If the macro breaks, nobody cries-
at least not where leadership sees.
This is our shadow app serenade,
the tune that the official roadmap never played.
Tiny tools in the dark, keeping promises made,
tap, tap, humming in the shade.
It’s a shadow app serenade,
half workaround, half parade.
When the process says “wait” and the customer stayed,
we keep the company running with a shadow app serenade.
But who knows the formula?
Who owns the key?
Who changed the field from “client”
to “customer ID”?
Who checks the token?
Who sees the feed?
Who knows the dashboard
is not what it claims to be?
Who told the bot
it could update the file?
Who gave the sheet
permission to reconcile?
It worked yesterday.
It should work today.
Don’t ask too loud.
Don’t take it away.
We patched a hole.
We crossed a gap.
We built a bridge
with a borrowed map.
We named a field.
We made a rule.
We taught the business
a hidden tool.
We didn’t mean to build the spine.
We only meant to save some time.
We didn’t mean to own the load.
We only paved a little road.
And now the road has traffic.
And now the traffic pays.
And now the little shortcut
is the way we count the days.
So laugh if you want to,
but don’t laugh too long.
There’s a kingdom in the margins
of this clever little song.
This is our shadow app serenade,
the tune that the official roadmap never played.
Tiny tools in the dark, keeping promises made,
tap, tap, humming in the shade.
This is our shadow app serenade,
not quite safe and not quite saved.
When the big machine stalls and the bright plans fade,
we keep the company running-
With a tracker!
With a macro!
With a dashboard!
With a flow!
With a chatbot!
With a lookup!
With a thing nobody knows!
Little fix, little flow,
little “please don’t let it show.”
Little spark, little trade,
little shadow app serenade.
Who supports it?
Shh.