The row

The six figures — the tool screenshots, the grids, and the timeline — are in the Substack cut. This page is the argument; the images are the receipt.

For most of my career the most dangerous document in the building was a spreadsheet.

Not the forecast. Not the contract. The LoE calculator. Level of Effort. The workbook turned what a customer wanted into how many people, for how many weeks, at what price, and its output went straight into the professional services statement of work, the document the customer would actually have to pay against. At Amelia, where I ran the solution architecture team, the LoE calc was Vishal's. He built it in 2020. By the time I left it was on its fifth version, and his name was still on the approval line.

It was never the arithmetic that made it dangerous. And the fix I am going to show you turned out not to be mine at all. I will get to both.

I want to be fair to the calculator before I take it apart. It was right. It was right the way a good tool is right: it asked for what it needed and did the arithmetic without opinion. Channels were checkboxes. Languages were a count. Integrations were a count of gateways. And use cases, where every hour of the actual work lived, had their own tab, one row each: a name, a rough intent count, whether there were integrations, and a complexity bucket. Low, Medium, High. The bucket drove the sprints; the sprints drove the price.

So the whole fight between what presales sold and what delivery had to build was expected to fit in one row of a spreadsheet, and mostly in one cell of that row. I am good at compression. That was impossible. And sometimes it compressed too far.

The row

Here is the shape of a Friday.

The rep needs a number by end of day; the customer wants Amelia on their ServiceNow queue. I open the calculator. Channel: the ServiceNow chat box, checked. Languages: one. Integrations: ServiceNow, one gateway. Use cases, row one: "Ticket management." The cursor sits on the complexity cell.

What that cell was about to do deserves a paragraph. The calculator produced an internal number: what the work would cost us. Onshore development, voice, ten or more use cases, custom integrations, and on a deal like this it could run north of $500,000 without trying. It was never the price. The price was the rep's to structure, and if it came to that, leadership could approve a discount; that was my argument every time, and it never once landed. Against a seven-figure contract the services were a fraction anyway. But the fraction was usually due up front, and the rest was subscription, and I will not get started on capex versus opex. So the number that came out of the calculator was the first number the rep saw, and no rep I ever worked with could unsee it.

I scoped it precisely once. The rep called within the hour.

"What are you trying to do, kill my sale? They are never going to pay that."

I had not said a word about the sale. I had counted what was in the row.

The ones I remember best did not wait for the row at all. They wanted the LoE before they would let us run discovery: a number, by Friday, for a thing nobody had been allowed to count. It was maddening. I gave them Medium. You can produce Medium without looking.

"How many use cases?" Vishal asked, when the sheet came to him.
"One," I said. "Or forty."
"The sheet has three boxes."
"I know what the sheet has."

It went in as Medium. Not because Medium was true; because Medium was the number that survived the rep. Delivery counted the forty in discovery, on their own calendar, after the SOW was signed.

Does this sound familiar. "Ticket management" is not a use case. Open a ticket. Look one up. Add a note to it. Change its priority. Hand it to someone else. Cancel it. Tell the person who opened it that something changed. Seven things, one kind of ticket. A hardware ticket needs an asset tag before the system will take it. An access ticket needs the application and the approver. A network ticket needs the site. A P1 routes to whoever is on call. In most instances each of those needs different inputs, routes differently, fails differently, and therefore gets built separately. The customer said "tickets." The rep said too high. The row said Medium.

I mapped the desk once. In July of 2025 I wrote an audit of my own organization, stage by stage, and the journey from a rep's first request to a signed contract had eleven stages.

1. Intake
2. Discovery
3. Demo
4. Scoping
5. Solutioning
6. The LoE
7. The SOW
8. The handoff to delivery
9. Proof of concept
10. Sandbox
11. The RFX mill

The number the customer signs is decided at stage six. Its inputs are gathered at stage four, and here is how I described stage four at the time, in my own audit:

"closer to a game of telephone where each participant is working off a different map, some of which are hand-drawn in pencil."
Inputs arrived "via Slack, back-channel AE requests, or a series of 'quick questions' in email, none of which get tracked."
"prone to wishful thinking ('It'll only take a sprint, right?')."
"Delivery's input, if it exists, is an afterthought."

Stage eight, the handoff itself, I called "the corporate version of dropping the baton and then arguing about whose fault it was."

The analysis that grew out of that audit put it flatter than I had: there was "no learning loop from actual delivery data back to estimation." Nobody ever went back to Vishal's workbook after the project shipped and wrote down what the row had actually cost. The calculator could not learn, because nothing was ever fed back to it.

Delivery held the bag. I wrote that sentence in the audit too, in nearly those words: solution architects scope on optimism, not realism, and delivery is left holding the bag. I ran the desk that did the scoping. The bag was mine to hand over.

The nouns

The row failed because it started with the wrong word. "Ticket management" is a verb phrase pretending to be a thing. A year before any of this had a name I had written the diagnosis into my team's objectives as a hypothesis: "we spend time asking the same discovery questions over multiple meetings and do a poor job of cataloging it." The catalog was the missing object. So the first move, and it is embarrassingly small, is to stop listing use cases and list the things.

A ticket. A user. A device. A knowledge article. Each one gets a name, the handful of attributes that matter (a ticket has a state, a priority, a category, a requester), and a type: is it a thing, a person, a system, or an agent. The systems those things live in get their own list, with the interfaces they expose, because that list is the integration plan whether or not anyone calls it that.

One rule about nouns, learned while trying to model a restaurant. A taco cannot READ. A taco might not even be an entity; it is an attribute of a menu and an order. If a noun cannot do any verb and can only be done to, it is probably a field on something else.

The LoE calc had a tab for use cases. It had no tab for nouns. No criticism of Vishal; nobody's calculator did.

The verbs

Then the verbs, and this is the part people fight me on: hold the list to seven: CREATE, READ, UPDATE, DELETE, INITIATE, RESPOND, NOTIFY. Four for the record, three for the conversation. Every real interaction in a business system is one of those seven done to one of the nouns, and if you think you have found an eighth, you have found a noun you forgot to list. The list stays closed on purpose.

Each verb has a direction. A user INITIATES a ticket; the ticket is INITIATED. I had a go-to line for this in workshops, tongue in cheek on purpose, and I am not too proud to print it: a man can eat a taco, but a taco cannot eat a man. It got a giggle every time, and it never needed a second explanation. A room that has laughed at the taco does not get direction wrong again. That sentence is the entire matrix: for every noun, which verbs it can do and which can be done to it, acting or reacting. Nothing else about the grid is harder than that. Write that down for four nouns and seven verbs and you have drawn a grid without meaning to.

I drew it on a whiteboard, because that is how I think, and because the customer was in the room.

The cells

Every cell in that grid is a question a delivery team would eventually ask anyway: can this actor do this verb to this thing, and if so, is it built, is it scoped, is it deliberately forbidden? So mark it. A filled circle for built, an empty one for scoped but not built, a dash for does not apply, and a stop sign for denied on purpose.

"Ticket management"                    CREATE  READ  UPDATE  DELETE  INITIATE  RESPOND  NOTIFY
Incident (any)                           ●      ●      ○       ⛔       ○         ●        ○
Incident: hardware (needs asset tag)     ●      ●      ○       ⛔       -         ●        ○
Incident: access (needs app + approver)  ●      ●      ○       ⛔       -         ●        ●
Incident: network (needs site)           ●      ●      ○       ⛔       ○         ●        ○
Incident: P1 (routes to on-call)         ●      ●      ●       ⛔       ○         ●        ●

Thirty-five cells where the row had one. Look at the DELETE column: all stop signs. True to how ServiceNow is run in practice: you cancel or close an incident, you do not delete it. Nobody had to remember to write that rule down. The grid asked, and the answer was no five times. Look at the empty circles: that is the scope ladder, discovered once, in the room with the customer, instead of re-discovered in a sprint review by a delivery team that was never in the room.

Which is why the tool is a grid and not a diagram; I learned that the expensive way, building three canvases first. A graph draws presence. Only a matrix draws absence. In a node diagram, "this role may not delete this", "we have not decided yet", and "this is structurally impossible" all render identically, as nothing, and the whole point of modelling a domain is the cells nothing fills.

A cell has a formal name. A role, a verb, a noun: a support agent may UPDATE an incident. The schema calls that a triplet, and a triplet is the smallest unit of capability the whole method knows about. Roles are not people; they are overlays. The same human is a requester on their own ticket and an approver on someone else's, and the grid is different for each.

Some cells have conditions. A requester may READ a ticket only if they opened it. An access request may be RESPONDED to only by someone who is not the requester. Those conditions are written next to the cell in a form a machine can check, so that "only if" stops being a sentence in a slide and becomes a line a validator will refuse to pass without.

I ran this on an IT service desk in August of 2025, in the designer I was building for the schema, and the first pass produced ten cells. An end user may CREATE their own record, INITIATE a ticket, READ their own tickets, and READ the knowledge base. An agent may RESPOND to a ticket and UPDATE it, READ a user and NOTIFY them, READ a device, and CREATE a knowledge article. Ten. Not one, and not forty. Ten is what the customer meant, and every dash in that grid is a question the customer answers before delivery has to.

The grid also answered the reps who wanted a number before discovery, and it did it without a speech. You cannot fill a grid you have not been allowed to look at. "Give me a number" became "for which cells?", and an empty grid with a price on it looks like exactly what it is.

The functions

None of that says how any cell gets done. On purpose. The separation is what survives contact with a real integration.

A cell says a role may do a verb to a noun. A separate table says which function does it today: this API call, this stored procedure, this robotic click-path, this webhook. One cell can bind to several functions; a function can serve several cells; and when the customer replaces their ticketing system, the cells do not change. Only the bindings do.

And here Vishal's calculator and my grid finally shake hands. His row wanted an integer. The grid has one: count the filled circles, weight each by the function that implements it, and you have a level of effort a delivery team can read line by line instead of arguing with a bucket. The number still comes out of a workbook. It just comes out of a bigger one.

And this is where the rep and I stop shouting. The rep can still get the number down; I want the number down too. But the only way to lower it now is to turn a filled circle into an empty one, in front of the customer, who watches which cell goes empty and signs the ladder that says when it comes back. A smaller package is a dossier with fewer filled circles, and everyone can see which ones. You cannot get a number down by yelling at Medium. You can get it down by choosing, cell by cell, with the person who is going to pay for it. The argument does not go away. It moves somewhere it can be settled.

The dossier

All of it, nouns, verbs, roles, cells, conditions, bindings, the systems, the knowledge articles the agent is allowed to read and the tags that route them, packs into one file with a version number and a schema reference at the top. Twenty-three constructs, seven verbs, and twenty-six controlled vocabularies so that "priority" means one thing across the whole file. It validates: a machine will tell you if you claimed a verb on a noun that cannot take it, or bound a cell to a function that does not exist, or left a triplet with no gate where one is required.

Opened, it is a set of tables; four of the twenty-three constructs have the word Matrix in their name, and Vishal would recognize the shape on sight.

The file is called a dossier, because of what the method is called: it is Domain Intelligence, and intelligence arrives as a dossier. A business, worked like a case. The method got its name at 11:40 on the night of May 1, 2025, in a chat where I was arguing with a machine about telcos; I have the timestamp because I keep everything. The specification underneath it is the Domain Intelligence Schema. The acronym is DIS, which I did not notice until the documentation started reading like a bit: DIS entity, DIS matrix, DIS dossier.

And because the file is machine-readable, it generates. I wrote twelve prompts and ran them in order, each one reading what the last one produced: the seed, the questions, the personas, the entities, the roles, the applications, the knowledge, the mode matrix, the triplets, the tags, the gates, and last the functions. A personal-banking agent went in as six use cases on a form and came out the other end as an agent definition, a collection of mock API calls the agent could hit, and a spec the platform could import, before anyone had written a line of the real integration. I had a test for whether a demo was real: hand the phone to the customer and say "here, you try," with full confidence it will not fail. A demo generated from the grid passes that test more often than one built by hand, because the grid had already listed everything the customer might try.

The pilot I wrote for it that August asked for a first dossier of at least thirty entities and sixty triplets covering seventy percent of a domain's intents, two workflows that beat the existing baseline on at least two metrics, and ten people trained to run the workshop. Those were targets. The largest dossier I have built since is forty-two entities and twenty roles, and it models my own estate; the method does not care whose nouns they are.

The inversion is the whole reason agents need it. The old way was top-down: pick a use case, gather requirements, implement. It worked when software executed the path you drew. Agents do not execute the path you drew; they call functions, and behavior composes from whatever functions they can reach. In that world the use case is not the unit; it is a projection. "Ticket management" was a projection of thirty-five cells onto one word. So the order flips: model the nouns, the verbs, the conditions, and who is allowed what, and let the valid use cases fall out of the grid. Some of them will be the ones the customer asked for. Some of them nobody asked for, and those are the ones that were worth the meeting.

I want to be precise about what the file is, because I have been imprecise about it before and paid for it. It is not the accountability layer. It is not, necessarily, a runtime layer at all. It is a design-and-build artifact: a table on a whiteboard before it is anything a runtime reads. Presales fills it in with the customer. Delivery reads the same grid and counts filled circles instead of picking a bucket. The agent's tool list is the column of filled circles. The rep negotiates on the same grid, one cell at a time.

Three different things carry the name. The schema is open: Apache-2.0, on its own domain, twenty-three files you can validate a dossier against tonight. The workshop that fills it in is not a document; it is a room with the people who own the nouns, and it is the work I do. The designer that draws the grid and the chain that generates from it are mine, and I am building them into something a team can license rather than something only I can run. The reference domain I keep for it is an HR operations unit, modelled on no customer: seven entities, seven verbs, eight roles, 392 cells, every one classified. 91 built, 40 scoped, 82 denied, 179 not applicable, nine gates. The DELETE column is 56 for 56 denied, because records are closed, superseded, or withdrawn and never deleted, and the tool will not accept the unit otherwise.

It enforces two rules and only two:

An unclassified cell is an unanswered question hiding as an omission.
A refusal that does not say where the need goes is not a decision; it is a shrug.

In 2025 I described it, internally, as a common language within the organization, something that translated the domain into a form every part of the company could digest. The sentence I use now is shorter.

Domain Intelligence is the contract that lets humans, agents, and sales reps all speak the same model.

The restaurant

I can show you the whole arc once, end to end, because one customer walked it.

In April of 2025 a national restaurant chain told us what they wanted for their service desk: a single pane of glass for their agents, no tab switching, and immediate ServiceNow ticket actions. Create. Update. Comment. Read that again. The ask arrived pre-verbed: three verbs on one noun. Customers do not ask for use cases. They ask for cells.

The cheap answer on the table was an iframe: wrap the other system's screen in ours and call it integrated. I wrote my boss a letter over that one. I told him I will never recommend an iframe anywhere, under any circumstance, and asked him to trust me that doing it right was also the strategic move.

I did the market homework too, because trust needs receipts: the competitors' consoles already sold customization like this, and the analysis put the addressable value of that one capability between $170 and $340 million a year, assumptions on the page.

The right answer was the grid, projected into a console: a widget is a small set of cells, a few verbs on one noun. Behind each widget, functions bound to the cells. A supervisor maps which functions a widget may call, which is the binding table wearing a settings screen. Access control decides which agents get which widget, which is the gate matrix wearing a permissions page. An agent types what they want in plain language, and the system picks the cell.

By June we had run the domain work and written it up; the document was literally titled Understanding The Domain. And the feature shipped, to my knowledge, agents in one pane with their three verbs. The deal closed too. $6.47 million, and the domain work is what carried the room. One summer, ask to signature.

And the calendar has one more entry I will report and not interpret. The deck with the three verbs on it is dated April 28. The schema got its name on the night of May 1. Four days. I was arguing about a different industry when the name landed, but the hand had just spent a month drawing ticket cells for a restaurant.

The customer never saw a schema. They saw their three verbs, on their noun, in one pane. That is what speaking the same model buys.

The trench

I did not develop this from a research agenda. I developed it at the presales-to-delivery boundary, with a calculator that had three boxes, reps who wanted the number lower or wanted it before discovery, and a delivery team that kept finding forty things in a row that said Medium.

I can show you where the desk's attention went instead. In May and June of 2025 I filed 406 items on my team's board. 163 of them were about demos. Thirteen touched the LoE, scoping, or the statement of work, and the one that said "Automate LoE Creation" sat at Blocked. Demos drew the applause; the calculator held the money.

And the row was not the only retyping. Alongside the calculator we were required to fill out a Word document called the Value Realization Framework. Nearly everything in it already lived in Salesforce, or in the LoE, or in the SOW; the same promise, typed a fourth time, into a template that delivery leadership insisted remain a Word template. I tried to automate it. The answer came back: "Just do your fucking job." We were an automation company. My job was filling in Word documents by hand. That was the day I knew I was out of there.

When I first tried to explain the grid, I explained it as a schema with a vocabulary of its own, and a schema is a hard thing to sell to people who wanted a faster spreadsheet. The shape of it got built; the restaurant proves that. The method for scoping with it did not get traction. In August of 2025 I had a twenty-three-page analysis drawn up that named Accenture, Deloitte and Capgemini's agentic "blueprints," with the press releases to prove they were coming, and argued that a dossier "is not a PowerPoint presentation; it is a structured, executable model of the business." The argument was right and it did not matter. I wrote it down anyway, and in November of 2025 I wrote the sentence I should have led with a year earlier: this is a specification language, not a runtime.

The market has since found its own words for the same problem. Deloitte's survey this August reports that nearly two-thirds of executives are reevaluating their business models because agentic AI "demands reinvention of processes and workflows in addition to technical deployment," with 74 percent expecting nearly half their processes to be redesigned around agents within four years and 21 percent saying their processes are ready. Accenture, in March, described the operating system leaders now need as one "where people orchestrate human and AI collaboration and AI executes within clear constraints." McKinsey, last September, put the operating model and its governance among the five pillars of an organization built around humans and agents working side by side.

None of them are describing my schema. They are describing the row.

The teenager

The part I did not know until this week.

Draw the grid the way I have been describing: nouns that hold state, a closed set of verbs, cells that say which act is allowed, conditions on the cells, and the rule that a use case is whatever paths the grid permits. I thought I was building a scoping method.

What I had drawn has a name. It is a Petri net: places, tokens, transitions, guards. The marking is the state. The paths are the reachability graph. "Use cases are an emergent property of the relationships between entities" is not my thesis; it is a sixty-year-old property of the mathematics, and it is checkable by machine.

Carl Adam Petri drew the notation in August of 1939, at thirteen years old, to describe chemistry. Molecules as tokens, reactions as transitions. He formalized it in his dissertation in 1962. The business-process world adopted it around 1998, when the academics proved a workflow could be a mathematical object with a correctness property: sound, or not. And then the industry walked away. The orchestrators that run today's automations, the DAG engines, the agent frameworks, dropped the formalism and kept the boxes. I came up through those tools, and the net was never on the syllabus. I re-derived it from a spreadsheet fight, the way Petri derived it from chemistry, and I found the territory the way I always do: after the hand.

Here the argument that the schema was too disciplined dies. The closed alphabet of seven verbs, the matrices, the refusal of an eighth verb: that is not pedantry. An open vocabulary has no properties; a closed one is what makes the net analyzable. You can ask a dossier "can this cell ever fire" or "does every opened path close" and get an answer from an algorithm instead of a meeting. The parts that sounded impractical were the mathematics.

And one cell of it is mine. You already know the distinction; you learned it in sixth grade. You raise your hand. Can I go to the bathroom? Yes, the teacher says, you can. And does not let you go. You sit there, needing to, while it dawns on you. May I go to the bathroom. Now you may. Can was never the question; can is a fact about you. May is a fact about the room, and only the authority in the room can answer it. A bare net only ever answers the first question: if the tokens are there, the transition fires. Enabled and allowed are the same predicate. Capability mistaken for permission; the oldest error there is, and exactly what handing an agent "ticket management" does. The agent asks can. Nobody in the row ever built the teacher. The grid splits them: the nouns and verbs say what can act; the cells and their conditions say what may.

If you want that in engineering terms, the split already has two engines. The facts, who reports to whom, who sits at which facility, who holds a live delegation for whom, compile to relationship tuples, the kind an authorization system like OpenFGA stores. The gates compile to policies, the kind Cedar evaluates: permit this principal, this action, on this resource, when. Can is a lookup. May is a decision. The grid is the one source both are generated from, and a decision comes back with the chain of authority that produced it and a hash you can keep.

In my reference unit a manager may open a leave request for a report only if a live delegation exists; acting on behalf is a grant, never an inference from hierarchy. That is The Beep's question answered before anything is delegated.

What neither the net nor the grid says is who answers when a cell is used. I wrote about the runtime shape of that failure in The Beep; building the design-time answer is the year I have had, and the next essay.

The calculator was right. The row was the lie. The grid was mathematics the whole time. A thirteen-year-old had it in 1939; I just had to lose the fight to find it.

Nathan Walker builds AI governance and enterprise platforms at Ravenhelm. He works where durability is non-negotiable. nwalker.cc · Substack cut