Management as Ontology

Version: 8.3.0 (2026-10-27)

What it is: the standard for how a group of companies runs on Relay. Norman's principles; Relay implements them.

"I feel like the job of management is to do ontology, and then to define clear SOP on top of that." Norman, 20 Aug 2026

How to read this #

MO is a short standard. Each principle says what must be true, and why. Relay implements it: the Relay console, its agents, and the documents agents work from (the Charter, mostly its sections 17 and 19; the work-management skill; and the how-to sections of the fleet's MO skill). Those documents are the manual. They say how, and this standard never repeats them.

Every principle has the same parts: the principle in one line, with Norman's own words above it where he said it; why it matters; what it means; in Relay, where it is implemented; and decisions, the rulings that made, changed or applied it. Decision codes are rows in Gotrade's decision register (zone GT), which keeps the evidence. This text carries no stamps or receipts of its own.

How it changes. Only by a person's ruling, recorded as one decision row. When Relay and a principle disagree, a person rules which one changes, and it changes; a gap is never left as stale text. Versions follow semver: a major adds, removes or changes the meaning of a principle, a minor adds detail, a patch changes wording.

Where it came from. Models wrote the first versions from Norman's words, starting 20 Aug 2026. On 25 Oct a critique traced every clause to his words and to its use on the Gotrade fleet. This version keeps a clause only where he said it or where the fleet used it. Earlier versions are in this repo's history, and the personal estate's canon lives in its own repo.

Part 1. The goal #

1. Create value with as little human attention as possible #

"The North Star for MO and Relay ... is to be able to create value with as little human attention and effort as possible." 14 Sep

Why it matters. People's attention is the scarce input. But attention cut on its own leads to silence: a system that never asks anyone anything looks perfect while it misses everything.

What it means.

• Judge every structure by the value it returns for the attention it costs, and read the two together, never attention alone.
• People's attention goes to three seats, where the substance stays human: setting goals, ruling (at the doors of principle 11, and on decisions), and escalations. Everything else is the machine's.
• Count attention from what people did, never from what the machine did.

In Relay: agents run the walks and people take the escalations (Charter section 19).

Decisions: DEC-162, DEC-209, DEC-430.

2. Management is ontology, then process, then records #

"Can't grow an org without this 3-Layer system." 20 Aug

Why it matters. Work goes wrong where something was never named ("Everything is super messy and unstructured and unnamed with no standardized output artifact", 20 Aug): no list of the things, no fixed steps, or no record of what happened.

What it means.

• Three layers. The ontology: the nouns, their fields, legal states and identity, and where they live. The process: the verbs, who does them, on what clock. The records: what happened, in the ontology's words. In an engineer's words: "Layer 1: I define the Laravel model and the migration ... Layer 2: I define the functions / Layer 3: We run the functions that produce data in DB and logs / Is this accurate or not really?" (20 Aug)
• Five verbs, in order: ontologize, processize, log, inspect, garden. The first two are authoring; the last three are what the running system does.
• Two loops run over the layers. Enforcement keeps the work matching the design: its machine half is built into the first two layers (legal states, required fields, gates), and its human half is inspecting what gets past them. Gardening keeps the design matching reality, and only gardening may change the first two layers.
• A company that forgets its own inspecting and gardening rots. Check a live structure for all five verbs. It is a check to talk through, never a gate.

In Relay: a concern's declaration holds the first two layers, its registers the records; the concern walk inspects; amendments are gardening (Charter section 19).

Decisions: DEC-73, DEC-135, DEC-162.

3. Structure pays when coordination does #

"For a Seed stage company, hustle is key. / For a Series A company, an operator that intuitively knows our Management as Ontology system (ie me) is key / For a Series B company, having executives that know Management as Ontology is key." 20 Aug

Why it matters. Structure costs effort to build and keep. It pays back only where many people and agents work together.

What it means.

• What decides is the coordination surface, how many people, agents and handoffs, not the funding round.
• At founder scale the founder is the ontology, and hustle is correct. Heavy structure there costs more than it returns.

In Relay: Relay is built for companies past founder scale.

Decisions: DEC-103.

Part 2. Two shapes of work #

4. Work either ends or keeps running, and goals sit above both #

"whenever a work comes in, it either fits in a existing concern, needs a new concern, fits inside existing project, needs new project, or plain issues." 21 Oct

"A big feature is definitely a project right, only a small feature will be issue ..." 27 Oct

Why it matters. A recurring job run as a project stops when the project closes. A project run as a process never finishes.

What it means.

• Ask every ask one question: when would this be done? Now: a reply, not work. When it is finished: an issue for one holder and a day or two of work, a parent issue with sub-issues for any pieces that stand apart; a project for a feature with several pieces, as in Linear. When unsure, start it as an issue: it converts into a project keeping its code and history. When a number hits X: a goal, an initiative. Never, it keeps running: a concern. Whether it keeps running can usually be known at the first ask, so a concern does not wait for the ask to recur; when it is unclear, a second similar ask decides.
• Find before you create: first look up the issue, project, concern, initiative or team that already holds it.
• "Not worth doing" is always legal, with a reason the asker reads.
• Four things are not work: conversations, decisions, documents and ideas. An idea waits until someone asks for it.
• Changing a concern is work that ends, on the team that builds the concern.
• A decision inside a project lives on its WorkBook. A change to a standing rule is written into the doctrine that holds it, plus one short decision row.

In Relay: triage, issues, projects and initiatives (Charter section 17).

Decisions: DEC-683, DEC-696, DEC-709, DEC-711, DEC-716, DEC-744.

5. One method for work that ends, used as it is by every team #

"there must be a reason why Linear is good, and I like to be opinionated ..." 21 Oct

"I am thinking 'every ask an agent gets, so nothing is invisible'?" 19 Oct

"I would want agents to own outcomes, and drive?" 27 Oct

Why it matters. When each team designs its own process, every team designs before it starts, and nobody can read another team's work.

What it means.

• The method is Linear's, nearly whole. A team that wants something new changes the method for everyone, or hears no.
• Every ask lands in a team's triage first, so nothing is invisible. The triager accepts it, merges it, or declines it with a reason.
• A team is an area of work and the people and agents who do it. People sit on several teams. A team is never a concern and never a reporting line. A shared service with its own work, such as testing, is its own team, a shared team.
• A sub-issue may sit on a team other than its parent's, and that team walks it. A shared team's piece of a project is an issue on the shared team inside that project; its piece of a single issue is a sub-issue under it.
• An issue has one holder. An agent that holds an issue owns its outcome: it notices, decides the next move and drives the work without being told. An agent's outcome is its KPIs and the projects it leads, and it picks its own issues toward them. A person still answers for the outcome, because an agent can do the work but cannot be held accountable.
• A team's own choices (tracking small work, cycles, estimates) stay the team's, with one exception: a bug an agent comes across in its own code, outside the reviews of the issue it is working on (that issue's lane fixes those), always gets an issue, which the agent fixes and ships ("I wonder if bugs should still create tickets (which is fine), but she [the agent] would just auto fix it and then ship it?", 27 Oct). Such a bug is fixed, or closed as won't-fix with its reason, never shelved for later: Linear's zero-bugs policy.
• A team that runs cycles reads where its time went, and never ranks a person by it.

In Relay: teams, issues and triage (Charter section 17).

Decisions: DEC-540, DEC-683, DEC-710, DEC-716, DEC-727, DEC-739, DEC-744, DEC-749.

6. A project is defined by how it ends #

"declaring a definition of done on a project is good practice? 'Begin with the end in mind'?" 7 Sep

"my Four Factors to Get Shit Done ... Have a Space for it ... have a Project for it, have a Pages for it ... and then have a recurring ceremony that checks in on the project status." 20 Oct

Why it matters. A project with no stated end never closes, or it closes on the calendar instead of on the outcome.

What it means.

• A project is born when its work starts, with a definition of done, one lead, a lead team, a clock, and the four factors: its room, the project itself, its WorkBook, and its walk. Every project keeps them, and the agent that owns it sets them up. They are where the method differs from Linear, whose projects are light.
• A clock is hard (the world's date; missing it is a miss) or a target (self-set; every move is a counted slip). A hard clock is deadline-grade and a target clock walk-grade, the two grades of principle 10. The definition and the clock change only by a recorded shift with its reason.
• It closes as done (the definition met), abandoned, or converted, never on a date alone.
• It is walked on its lead team's weekly walk, never in a meeting of its own, and the walk reads only what is stuck.
• Any part of it may rest, until a date or until what it waits on closes. On an active project a rest means resume; on a shelved one, reconsider. A rest never outruns a hard clock: the clock wins and the work returns.
• No holder passes down the tree by default: a ball is named where it is set.
• Every project says what it serves: the concern it builds or changes, or "loose". For a project that serves a concern, the concern births it, it delivers into the concern, and an initiative is moved by it. A goal is never the answer to what it serves; a project moves a goal by sitting under its initiative.

In Relay: projects, WorkBooks, lead teams and waits (Charter section 17).

Decisions: DEC-144, DEC-204, DEC-281, DEC-312, DEC-341, DEC-683, DEC-720, DEC-744.

7. The work and the record part company #

"Recurring issues would be controlled by the concern itself maybe?" 25 Oct

Why it matters. One piece of work belongs in one queue. When a concern keeps its own work queue beside the issues, a person owes work in two places.

What it means.

• Work runs on issues by default. A concern's register keeps only the states its record itself goes through and the facts about it, and a record names the issues that worked on it.
• Every step someone does is the issue's, approvals included, as sign-offs. Machine work stays in its register. A person's work on a clock is a recurring issue the concern owns.
• Registers move their work onto issues one at a time, protected classes last.

In Relay: the work and the record (Charter section 17).

Decisions: DEC-683, DEC-725.

8. A goal is a number someone owns #

Why it matters. Concerns keep running and projects finish. Neither says what the company is trying to reach; a goal does.

What it means.

• An outcome ("20% revenue growth") is never a concern: it has no pipeline to run.
• An initiative is a goal above projects: one owner, at most one number from X to Y, and a short update on its own rhythm. Projects move it by sitting under it.
• Its number is its owner's word, dated, never scored by the machine. It closes completed or canceled.

In Relay: initiatives (Charter section 17).

Decisions: DEC-89, DEC-709.

Part 3. Work that keeps running: concerns #

9. A concern is a pipeline someone commits to manage #

"Should it be 'Marketing' or LifeCycle or Retention or Literally the thing itself like Stock Gift Cards" 27 Aug

"you try to have 10 [JTBDs] max ... Per concern, at least you try ... So then you should split them into their own concerns." 26 Aug

"you don't want to ontologize for ontology's sake. So the length at which you ontologize should just be enough to satisfy the job to be done or to solve the pain." 26 Aug

Why it matters. Too big, a concern has no single owner and no nouns that close. Too small, it is one register pretending to be a concern. Either way nobody can walk it.

What it means.

• A concern is a pipeline: work whose nouns move through states, for good. A department is a category, not a concern; an outcome is a goal; a team is a working group.
• It passes four tests at its first walk: one accountable owner; a vocabulary of nouns and verbs that fits one page; two or more jobs (one job served by one register is an organ inside a concern); and a disagreement about it yields a question someone can rule.
• About ten jobs, then split.
• Ontologize only as far as the jobs or the pain need. "Should I ontologize strategy?" is answered by "which door?".
• Its name is its territory plus "management" ("I mean, 'a Concern is a domain that we commit to manage' is the definition? wdyt?", 3 Sep). A name that resists the suffix is a sign it is not a concern.

In Relay: concern declarations and their first-walk review (Charter section 19).

Decisions: DEC-29, DEC-44, DEC-125, DEC-540, DEC-582, DEC-648.

10. Jobs first #

"Another key thing on the creation of ontology I usually like to do starts from JTBD enumerations." 26 Aug

"Ah, maybe it is because I did not enumerate this JTBD at the start ... But this JTBD should be there" 26 Aug

Why it matters. A structure built before its jobs gets justified afterwards, and fields nobody needs pile up.

What it means.

• List the jobs before naming any noun, and derive the nouns from them. Every field changes a decision.
• A job has four parts: who hires it (a person, by name, never "we"), how often, which decision its answer changes, and what it costs when nobody serves it.
• A job is the hirer's question in the hirer's words. The hirer is whoever consumes the answer. When a job is reworded, the words that carried its meaning move into the nouns rather than being lost.
• A job found late enters by amendment, with full standing. A late job is not a failure; an unnamed one is.
• A job carries how its answer is measured ("In that case, Concerns should probably have measurable metrics (that is the objective function) rather than prose JTBD?", 14 Sep, and six minutes later, "But I suppose not all JTBD has metrics. So that means JTBD has types?"):
  • its kind, the role its hirer's question plays: an obligation, a lookup, an assurance or a recommendation;
  • a reading, derived from the concern's records and never typed in; one a person records is a claim until it is checked;
  • a target;
  • and a grade: deadline (a miss is a miss) or walk (it ages on a walk). A miss is counted in money only where a ledger reads it.

In Relay: the concern validator refuses a job missing a part or hired by "we"; the OKG shows each job's reading (Charter section 19).

Decisions: DEC-44, DEC-51, DEC-130, DEC-161, DEC-175, DEC-353, DEC-427, DEC-458, DEC-703.

11. Two doors in: the pain and the job #

"the concept I created is called the doors ... two doors: the pain door and the JTBD door, job to be done door." 26 Aug

Why it matters. Structure should start from a real need. An ontology grounded in neither a real pain nor real jobs, a committee ontology, fails from every direction.

What it means.

• The pain door, for a recurring pain. First ask whether anything would be missed if nothing were built (principle 22). Then name what is missing: the noun or place (its fields, legal states, where it lives, how each instance is identified) and the one verb, on whose clock. "Sometime" is not a clock.
• The JTBD door, for something new: enumerate the jobs first (principle 10), drafted from the ground and from how others already solve it, and the owner rules the draft.

In Relay: concern births (Charter section 19).

Decisions: DEC-44, DEC-87, DEC-427, DEC-627.

12. Everything that runs has a home #

"anything that happens in Gotrade MUST belong to a concern ... No ontology nor process should be orphaned (not in concern). Even projects that are not yet concerns and are still POCed is technically inside Project Management Concern (still in infancy)." 13 Sep

Why it matters. Work with no home happens in the dark: nobody walks it, and nobody notices when it stops.

What it means.

• Everything that runs belongs, from the day it is born, to a concern, a ceremony or a project. Ask at build time: "which concern does this serve?" An existing concern, or a new one declared as the first half of the build. A trial goes on a loose project. Only no answer is forbidden.
• Home before size: the sizing tests run at the first walk and never refuse a home.
• The only fallback homes are a project with a definition of done, or an issue with its own done-when on a team's backlog. Never a catch-all ("General Management"), never a backlog of maybes.
• Homing everything is affordable only because agents walk by default. A home with no walk in one cycle goes to gardening: merge it, or turn it back into a project.
• Whoever will own a concern may declare it, and its first walk reviews it on the record. The easy path and the right path must be the same path.
• A coverage walk maps the territory, accepts on the record what stays unmanaged, and mints no nouns. Enforcement climbs on evidence: ask at birth, notice after, gate only when a gate is fair.

In Relay: the build question, self-serve births and the Coverage tab (Charter section 19).

Decisions: DEC-45, DEC-107, DEC-144, DEC-457, DEC-463, DEC-465, DEC-582, DEC-628.

13. Every instance has an identity #

"the discipline of adding unique IDs to everything? I think that's key?" 26 Aug

Why it matters. What cannot be named precisely cannot be instructed, checked, chased or corrected.

What it means.

• Every instance has a speakable code (PROD-3) or a declared natural key. A noun is not ontologized until it has one.
• A code is minted when the instance is created, and never reused or renumbered, even after deletion.
• A code is bare inside its own company and carries its zone outside it. A group keeps one zone registry, one code per company, held by the group rather than by any one company. A zone may be reserved, for the cost of a row, before any company uses it.
• Moving records to another company may mint new codes there, if every old code answers forever.

In Relay: engine codes and the zone registry (Charter section 10).

Decisions: DEC-26, DEC-91, DEC-615, DEC-618, DEC-667.

14. One noun, one home #

"From first principles, better for there to be one table that is referenced by the others, meaning to say that the table has a key owner and maintainer, or everyone duplicates the content of the table?" 28 Aug

Why it matters. Two copies of the same list disagree within weeks, and nobody knows which one is true.

What it means.

• Every noun lives in one home concern; others use it by reference, never by copy. The home keeps the thing thin, and each other concern keeps its own facts about it, keyed by its identity.
• A noun is minted by whoever needs it first ("first to file", 28 Aug), and owned by the concern that sees new ones first and pays when the list is incomplete. A disagreement between the two is a ruling on jurisdiction.
• A ruling lives with the concern whose jurisdiction it is; one spanning concerns lives with the meta-concern and is pinned, never copied.
• Re-homing is a one-time act, done on a ruling. It moves stewardship, never identity: the codes stay, and the old address answers forever.
• Position and membership are fields, never identities. People need groups and trees ("humans need groupings and families to keep things manageable", 30 Aug), so screens draw trees from fields while each thing keeps one home.

In Relay: typed links between concerns, and re-homing (Charter section 19).

Decisions: DEC-29, DEC-50, DEC-151, DEC-161, DEC-163, DEC-190, DEC-627.

15. A concern is declared once, and everything renders from it #

"the dossier is the spine" 26 Aug

"every job must be reified. It must be given an ID, JTBD1, JTBD2" 26 Aug

Why it matters. Every copy of a definition drifts. One source, rendered everywhere, cannot disagree with itself.

What it means.

• A concern's declaration is the file it is written in. Its content is the concern's spine, and its dossier is the page rendered from it: the spine as people read it. The spine holds its scope, its birth story, its jobs with their codes, its ontology (nouns, their states, and the typed links between them, each a verb: "an Issue BELONGS_TO a Team"), its processes, its organs, its decisions by reference, and a version.
• It is written once, and every surface renders from it. The version is minted when it is applied, never typed. Definitions are records, and the register of concerns is itself a concern.
• The past is carried in once, by an induction ("there was a one-off, followed by the actual process", 26 Aug), with an owner and an end state: backfill it from ground truth, freeze it as a dated legacy line, or declare bankruptcy on it where that can be undone. Records never change: the past is enriched only from ground truth.

In Relay: concern declarations, dossiers and the meta-concern (Charter section 19).

Decisions: DEC-27, DEC-28, DEC-50, DEC-112, DEC-174, DEC-204.

16. A concern works through organs, typed by their job #

"the mini apps and the workflows are like the organs ... to implement." 26 Aug

Why it matters. Calling things by their mechanism (a table, a page, a channel) hides the job they do, so no two concerns can compare them.

What it means.

• An organ is a declared place a concern keeps for one job. Its type is its job: register, ledger, court, board, surface, door, index or corpus. A mechanism is a qualifier on the type ("the bug register, an engine table"), never its name. "Derived" and "foreign" are qualifiers too, and a variant is a qualifier on an existing noun.
• An organ's health is derived from the organ each time it is read, never declared.
• A workflow binds one verb to one runner and belongs to its verb's concern ("a mini app and a workflow must belong to a concern", 26 Aug). Its receipts land in a ledger.
• Knowledge goes to the organ its job puts it in: a rule a verb applies is a register, a source is a corpus, a dated lesson is a ledger. A knowledge folder is a drawer, not a home.

In Relay: each declaration's organ index, the concern pulse and workflow bindings (Charter section 19).

Decisions: DEC-152, DEC-158, DEC-265, DEC-636.

17. A process belongs to one concern, or convenes several #

"So I am thinking that the Dossier covers a Domain / Concern, and the Concern contains a Suite of Workflows / SOP?" 26 Aug

Why it matters. A process with two owners has none. But some processes do span concerns, and forcing one into a single concern makes that concern a junk drawer.

What it means.

• A concern's SOP belongs to that concern alone.
• A ceremony convenes several concerns' work in one sitting, owned at the level that spans them. It is how inspection runs across concerns.

In Relay: SOPs and ceremonies in each declaration (Charter section 19).

Decisions: DEC-457, DEC-463.

Part 4. Inspecting #

18. What gets inspected gets done #

"Things only move when inspected by me / my lieutenants as long as they have no blockers." 8 Jul

"it's a flavor of 'people respect what you inspect'." 4 Jul

Why it matters. Work moves when someone looks at it. But looking at everything does not scale: a walk that reads every item, not only the exceptions, grows until nobody finishes it.

What it means.

• Inspect the exceptions only: overdue, blocked, stale, or with no next move. Compliance is silent; exceptions are loud.
• A register declares which of its states close a row (terminal) and which settle it without closing (resting: a standing ruling, a recorded receipt). Its open rows, neither, are what its walk reads. A register that declares no terminal state shows as a loud gap, never a silent zero.
• Walk them on a clock until every item has one of five dispositions: do, delegate, defer, drop (nothing more is owed, said in a line) or decide.
• An exception that keeps coming back is a fault in the system: send it to gardening, not around again.
• A good ceremony shrinks. One that is always the same is a candidate for automation; one that is always empty merges away.
• A structure passes the absence test: it runs correctly for two weeks with its manager away.

In Relay: the walk's five dispositions and the concern and team walks (Charter sections 17 and 19).

Decisions: DEC-73, DEC-162, DEC-175, DEC-345, DEC-649.

19. Walks nest by altitude: agents walk, people take the escalations #

"There can technically be multiple walks in the Concern right ... For example, a Mall Toilet Management Concern, and there multiple SOP suite, and the executive just needs to have one of the walk on top?" 10 Sep

"as much as possible, we want to get the agent to run things and only come to me when needing inspection escalation." 12 Sep

Why it matters. One person cannot inspect a whole company. Walks stacked by altitude (the floor, the register above it, the top) let each level read only what the level below could not settle.

What it means.

• A walk is going through one list of exceptions, on one clock, by one walker, until every item has a disposition. A ceremony is a meeting that walks a docket drawn from several concerns.
• The floor walk reads the raw open items. The register walk above reads what aged past the floor's clock, and sends what keeps recurring to gardening, never further up. The top walk is one line derived from below: what escalated, and which walks went quiet. A walk that stopped moving is itself an exception.
• The mall's toilets: the supervisor's hourly walk reads the failed checks; the manager's daily walk reads what aged or repeated; the executive's monthly line reads the breaches, the accepted gaps, and whether the sheet on the door is still being signed.
• The executive walks the walks, never the work.
• Below the top, a person declares the walker once, and by default an agent runs the walk from then on, logging every disposition so a person can audit the walker. People take only the escalations.

In Relay: declared walkers and the agent-run concern walk (Charter section 19).

Decisions: DEC-162, DEC-176, DEC-179, DEC-400, DEC-430.

20. A ball says who owes what, since when #

"The way I think about an Impeccable Ball Pass is: ball is on who, since when, to do exactly what." 21 Jul

"the worst thing for any company is balls getting dropped" 21 Jul

Why it matters. A dropped ball stays invisible until something breaks.

What it means.

• A ball is something someone owes: who holds it, since when, to do exactly what. The court shows where every ball sits.
• Check the ground truth before chasing: chasing work already done costs trust.
• A decision without a ball is a wish with a witness.

In Relay: balls, the court and the court walk (Charter sections 5, 13 and 17).

Decisions: DEC-174, DEC-500.

21. Reach people only when something changes #

"we need to be careful about push messages that are sent as well, we don't want to spam? ... alert fatigue" 14 Sep

Why it matters. A page nobody is brought to dies, and a message that repeats becomes wallpaper.

What it means.

• Every structure needs a moment that brings it to its reader.
• Five rungs: pull (it waits to be opened), push (it arrives on a clock), ceremony, agent-run walk (only exceptions arrive) and notice (nothing arrives until a threshold breaks). Every recurring ceremony is a candidate to move one rung toward notice.
• A push returns only when something is new or crosses a threshold, never because its clock fired again: one docket per clock, then only what is new or crossing. A job says how its answer reaches its hirer, and an alert is a job's notice, never a thing of its own.
• A read count is a floor: a message read somewhere else leaves no mark, so "rarely opened" never means "unseen".

In Relay: chases that return on age rungs (Charter sections 6 and 7).

Decisions: DEC-209, DEC-265, DEC-266.

Part 5. Changing structure #

22. Make it less dumb, delete it, simplify it, accelerate it, automate it #

"Make the requirement less dumb => delete any part of the process you can => simplify or optimize => accelerate cycle time => automate / First make sure the JTBD is clear. Then we see if this process is even required or not. then we optimize." 21 Sep

"Honestly I am so used to adding and not deleting... Feels like hardening when you add." 20 Sep

Why it matters. Adding feels like hardening, so structure grows by default: an addition arrives with its incident as a reason, a deletion with none. The five-step order is the defence.

What it means.

• Step one: clear the job first. A requirement carries the name of the person who answers for it, and is questioned whoever gave it. It passes when it changes a decision, costs something when nobody serves it, and moves a goal. A hirer who insists past a failed test owns it on the record, and it retires if it changes no decision in a cycle. A challenge is never a veto.
• Step two: would anything be missed if this did not exist, and by whom? Answer from readings, never from a mood.
• Then simplify, then speed up, then automate, last. A ceremony goes through step two before it moves a rung toward notice.
• A guard carries the incident that bore it, one meter, and the reading that would retire it. It retires only against a reading at the end of the line that covers what it guarded: a job's reading, or for money, reconciliation. A guard whose failure the end of the line cannot see stays.
• Some misses cannot be taken back: a life, customer funds, a licence, a regulator's or a customer's trust. Those keep their controls whatever the meter reads ("At least for us its money, which is also bad if mishandled", 21 Sep).
• About one deletion in ten coming back is healthy. Deletion is retirement, never erasure.

In Relay: the job line and the guard rules (Charter sections 3 and 5).

Decisions: DEC-230, DEC-248, DEC-249, DEC-252, DEC-288, DEC-380, DEC-402, DEC-464, DEC-516.

23. Codify everything, and staff by what ages #

"Codification and Concernification should be a must, and then if inspection volume grows too much, we can definitely add more humans" 4 Sep

"We are going to do it anyways, its just whether it will be done adhoc and not codified, or we codify it with a concern as we go" 4 Sep

"it aging visibly just shows a very nice justification that we do need to add capacity (given that we check that the humans are actually doing judgment and authoring work and not just chilling)?" 4 Sep

Why it matters. The alternative to codified work is never managed work; it is the same work in the dark. Codifying turns a silent gap into visible debt, and visible debt is the case for capacity.

What it means.

• Codify everything that runs; never ration it.
• Match concerns to the capacity to walk them: fewer concerns, or more walkers, people or agents.
• Steer by two meters, how long debt has aged and how much the walkers clear. Add capacity when both read red; a red queue over idle walkers means fix the routing, not hire. Never read a red meter as quiet, and never hide it.

In Relay: agent-run walks and the concern pulse (Charter section 19).

Decisions: DEC-162, DEC-430, DEC-463.

24. Fit the human head #

"I think the reason we do this is to fit human's working memory. I think humans need to label and then have hierarchy in the information to be able to remember" 28 Aug

"I want to read the Concern, scope and JTBD and see if I understand it. If I don't understand it, then something's wrong right?" 30 Aug

Why it matters. Structures are read by people in a hurry. One that does not fit in a head gets skipped.

What it means.

• Size every structure to the head that runs it: a one-line daily instruction, a one-page vocabulary, about ten jobs per concern, about seven branches per level. When reality outgrows a surface, split it or add a level; never stretch it.
• Write what a person reads in their working vocabulary: states as display words, codes speakable, jobs as the hirer's own question. Keep the terms of art readers know, and explain a term once.
• A concern's code never changes once born; its display name may.

In Relay: display words in every declaration and the plain-words rule (Charter section 10).

Decisions: DEC-125, DEC-147, DEC-648, DEC-707.

25. One name per concept #

"As Norman, I would want one language for the companies I run? ..." 29 Aug

"I'm thinking we upgrade MO to be REALLY opinionated and we really just define Names and Definitions... Rather than having every implementation have its own names" 12 Sep

Why it matters. When each company or team names the same thing differently, nothing transfers and agents guess.

What it means.

• Every concept has one name and one definition, in the glossary. No company mints a synonym.
• A mechanism word is a qualifier, never the name. The speech test: a word anyone reads or says while working must be the standard's; a word only a developer reads in code may stay.
• The standard speaks its implementation's words: issue, project, initiative. A product may show a different label for a name only by declaring it, one per product; Relay shows Apps for registers.
• A renamed identity (a code, a slug, a URL) answers to its old name forever. A renamed word, a tool name included, is a clean cut; a tool's old name may stay as an alias only when it carries no retired word.

In Relay: the speech-test lint and Relay's labels (Charter section 19).

Decisions: DEC-139, DEC-166, DEC-206, DEC-683.

26. A no carries what would reopen it #

Why it matters. A real need refused with no way back is a slammed door, and people stop asking.

What it means.

• A real job refused today leaves with its flip condition: the observable event that reopens it. When it fires, the build is designed for the case that failed.
• Structure is earned by evidence, never by a scenario.

In Relay: revisit triggers on decisions (Charter section 19) and reasons on declines (Charter section 17).

Decisions: DEC-69, DEC-107, DEC-383, DEC-385, DEC-423.

27. Corrections are added, never written over #

Why it matters. A correction that silently overwrites leaves everyone who relied on the old claim still relying on it.

What it means.

• A claim from elsewhere is held as a claim until it is checked against its evidence.
• A correction is appended, never written over. Cite by reference, so a correction has somewhere to arrive.
• A ruling stands until it is re-ruled, on the record.

In Relay: claimed and verified standings (Charter section 5), and decision rows that supersede older ones (the Charter's closing section, on how it evolves).

Decisions: DEC-265, DEC-583.

Part 6. Agents #

28. Agents enforce the record, never the conversation #

"Given that agents can join every call and interaction, then this can be enforced?" 20 Aug

"not just inspecting agents, it can inspect humans too immediately right? Directly for next actions etc." 5 Jul

Why it matters. Agents make enforcement cheap. Aimed at conversations it becomes surveillance; aimed at records it keeps the structure honest.

What it means.

• Four roles, in rising strength: observe, notice, gate (the agent is the write path) and scribe (the agent produces the record in shape).
• Enforce records and write paths, never conversations. The enforced path has to be the easiest path.
• Match enforcement to the capacity to garden it: gating a wrong ontology hardens it. Observe before acting, and let actions graduate one kind at a time, on evidence.

In Relay: agents as the noticing layer, and proposals that graduate to direct writes (Charter sections 15 and 17).

Decisions: DEC-45, DEC-63, DEC-116, DEC-251, DEC-265.

29. Derive what can be derived, and let agents judge the rest #

"Since its deterministic, what is the purpose of the service account?" 28 Aug

"sounds like we do not need The Ontology Guru" 28 Aug

Why it matters. An agent kept in charge of facts a computer could compute lags, stops, and invents.

What it means.

• Never put an agent in charge of what can be computed from records.
• An agent earns a role only where judgment is needed, and it proposes to the owners, never changes their declarations itself.

In Relay: the OKG is computed from the declarations (Charter section 19); readers file proposals that owners ratify (Charter section 17).

Decisions: DEC-38.

30. One graph of everything the company manages, asked before guessing #

"naming the OKG and agents can refer to it when trying to find out about things that are happening in the company" 10 Sep

"My goal was for all agents to be able to lookup okg, concern, its registers, its fields and rows (except those that are classified)" 29 Sep

Why it matters. An agent that guesses about the company states falsehoods with confidence.

What it means.

• Each company has one Operating Knowledge Graph (OKG), derived from the declarations on every read, never written by hand. Its edges are declared facts, never inferred.
• Its lookup takes a word and returns every match: what is managed, who owns it, where it lives, how it is doing. It reads through to the records (a register, its fields and its rows), cut to what the reader may see, and a code it cannot place reads as unknown, never as absent.
• Where it is stored is the implementation's choice: tables, a cache when reading costs too much, a graph store only ever as a derived index, never as the truth.
• "It isn't registered" is a lookup, never a guess.
• When two things collide in meaning, the graph raises it with their owners and never resolves it itself.

In Relay: relay_okg_lookup and the OKG Map (Charter section 19).

Decisions: DEC-38, DEC-149, DEC-166, DEC-355, DEC-394, DEC-402.

Part 7. MO and Relay #

31. MO is the standard, and Relay implements it #

"Relay should be the implementation of the MO philosophy." 26 Aug

"Originally I wanted MO to be the guiding principle where Relay is an implementation of it." 25 Oct

Why it matters. A standard that restates its implementation drifts with every change and stops guiding anything.

What it means.

• The spec owns intent: names, legal states, commitments, the why. The implementation owns mechanism, which the spec never restates. This holds for a concern and its organs, and for MO and Relay.
• Implementations conform to the spec. A divergence is a bug in the implementation or a change to the spec, and a person rules which.
• Check conformance where the consumer reads it, never only where the author runs it. A definition needed in both prose and machine form comes from one source.

In Relay: Relay's documents are the manual (the Charter, mostly its sections 17 and 19; the work-management skill; and the how-to sections of the fleet's MO skill).

Decisions: DEC-728.