A few days ago I was explaining orgschema to a CFO. After about ten minutes he stopped me and said: “But where is the uniqueness? Everything you described looks obvious. It seems everyone already starts from customer needs — in venture capital, that is the basics.”

He was right. And he was right in a way that exposes a marketing failure on my part.

“Start from the customer” is not new and cannot be new. It has been preached in different forms for at least twenty years: Jobs-to-be-Done from Christensen, Customer Development from Steve Blank, Lean Startup from Ries, Design Thinking from IDEO, Outcome-Driven Innovation from Ulwick, user stories in Agile since 1999, Behavior-Driven Development with Gherkin from Dan North, Service Blueprinting from Lynn Shostack since 1984. Even Norton and Kaplan’s Balanced Scorecard puts the customer perspective on top. In venture capital, customer-centricity is the floor, not the contribution. If orgschema is positioned as “we discovered that the customer matters” — it does not survive the conversation for a second.

So the real differentiator is not in the posture of starting from the customer. It is in how that posture becomes an executable artifact. This article makes the comparison honestly, in a table that does not need any of orgschema’s metaphors to do its work.

What the Neighbouring Methodologies Actually Do

Each of the following methodologies has solved part of the problem orgschema is trying to bundle. None of them has solved the whole problem.

BDD/ATDD writes tests in the language of the customer, but applies them to code. A barista does not run under Cucumber. BPMN and Petri nets model processes formally but do not check whether the process actually satisfies a top-level customer requirement — the link “process → why the customer wants it” lives in the analyst’s head. ISO 9001 has quality objectives and SOPs, but they live in different documents and are reconciled by an annual audit, not by continuous validation. Terraform / Ansible / IaC version-control infrastructure but have no feedback loop to customer experience: Terraform does not know why you are bringing up that server. Service Blueprint draws the customer journey and the back-stage operations, but it is a workshop picture, not a machine-readable specification you can run through CI. OKRs and SLO/SLA (including the Google SRE book) link outcome to process but do not form a six-level chain all the way down to suppliers.

Each neighbouring methodology has either the top (customer) or the bottom (process/code) — but almost nowhere is there a formally verifiable link between them across all levels at once. Usually the link is declarative: “we do this because the customer wants it.” You cannot prove it programmatically.

The Twelve-Property Test

I built a comparison table to make the discussion checkable. The criteria are chosen to test structural properties (what each methodology can do by design), not popularity, market share, or tooling maturity — those are real, important, and unfavourable to orgschema. We will get to them at the end.

* “works, but only in its own domain”: BDD validates code, IaC validates infrastructure. Neither descends to business operations or rises to customer experience.

How to Read This Table Without Self-Deception

A column that is fully filled is more often a sign that the criteria were chosen to flatter that column than a sign that the column actually wins. I want to be explicit about which side of that line this table is on, because the orgschema column is fully filled and the reader should know exactly why.

The twelve properties were not chosen to give orgschema a clean sweep. They were chosen to describe what a unified specification cascade would have to provide if it existed: bidirectional traceability, machine-validated seams between levels, observer-agnostic lower layers, supplier scope, schema/data separation, forkability. These are not arbitrary criteria. They are the structural commitments any methodology that tries to build the cascade has to implement. Any framework that does not build the cascade will be sparse on these rows by design — not because the framework is bad, but because the framework is not trying to do the same thing.

This is the part that matters: BDD is not trying to manage suppliers. ISO 9001 is not trying to be machine-readable. Service Blueprint is not trying to run in CI. BPMN is not trying to bind processes upward to customer requirements. Their empty cells are not failures. They are scope. Each of those methodologies wins on the criteria its authors actually optimized for, and the right way to read the table is “each column is full on the criteria it was designed against, and orgschema’s criteria are the cascade-shaped subset.”

What the table proves, then, is not that orgschema is the best at any single property. It proves that the cascade is buildable in one artifact format — which is the question the CFO was asking and which no single methodology, taken alone, has previously answered. If the criteria were different — production deployments, tooling maturity, certified practitioners, market share, depth of executive training — the picture would not invert in orgschema’s favour. ISO would dominate. BDD would have a polished ecosystem orgschema cannot match. The honest reading of the orgschema column is therefore: by structural design, yes; by industrial maturity, not yet. The right-hand column is a claim about what is possible to specify, not a claim about what is currently in production.

What the Table Actually Says

If you read it row by row, almost every individual property already exists in one of the neighbouring methodologies:

• “From the customer” — Service Blueprint and OKR.

• “Machine-readable customer spec” — BDD.

• “Machine-readable process spec” — BPMN.

• “Satisfaction check” — BDD (in code) and IaC (in infrastructure).

• “Continuous validation” — BDD, IaC, partly SRE.

• “Version control” — anything file-based.

• “Supply chain in scope” — ISO 9001.

• “Forkability” — hinted at in BDD and IaC modules.

Not one of these properties on its own is a discovery. The orgschema delta is that all twelve properties are reduced to a single end-to-end chain in a single artifact format. No existing methodology fills more than five or six cells simultaneously:

• BDD is strong on cells 2, 3, 4, 6, 7 — but only in the code domain, with no suppliers, no perception, no non-human customer.

• BPMN is strong on 3, 9 — but does not link upward to the customer and does not validate continuously.

• ISO 9001 covers 9 and partly 1, but fails everything machine-readable and continuous.

• IaC is strong on 3, 4, 6, 7 — but outside business operations, without customer or perception.

• Service Blueprint covers 1 and partly 9, 12 — but it is a picture, not an executable specification.

• OKR + SLO covers 1 and partly 2, 4, 7 — but does not formalise the lower levels or processes.

Orgschema is the first attempt I know of to put all twelve columns under one roof. Its real claim is not “we discovered customer-centricity” but “we are removing the seams between BDD, BPMN, ISO, IaC, Service Blueprint, and OKR.”

The Six Honest Differentiators

If I had to compress those twelve columns into six structural claims, they would be:

1. Bidirectional traceability with machine validation at each seam. This is not “all layers are linked to the customer.” It is “we can answer programmatically: does this process have an upward trace to at least one L0 customer requirement, and if not, it is waste.” In llms.txt this is called waste detection. I do not know another methodology in which dead-code detection has been applied to organisational processes. In ISO it definitely does not exist; an unused SOP can live there for a decade.

2. Continuous certification by commit hash. This is a radical break with the “we are certified for 2026” model. The analogy: in DevOps, ten years ago, the field already moved past “we deployed, it works” to “every commit runs the tests.” Orgschema transfers that culture to compliance and operations. The idea itself is not original — it is DevOps culture — but its application to non-IT operations is rare.

3. Observer-agnostic lower levels. The claim that L2-L5 are invariant to customer type (human / algorithm / hybrid). Most customer-centric approaches violate this, explicitly or implicitly: Jobs-to-be-Done and Design Thinking are built around the human observer. For Digital Product Passport and machine-to-machine commerce you need a methodology where the specification works the same for both. Here orgschema makes a structural rather than a marketing claim. Whether it works in practice is a question of validation, but the claim itself is non-trivial.

4. Fork instead of franchise as the replication model. Franchising legally and operationally requires execution sameness: the same supplier, the same SOP, the same store interior. Orgschema says: replicate the tests (L0-L2), re-implement the bottom (L3-L5) for the local context. This is not cosmetic. It is a different model of responsibility and a different royalty structure. To my eye, this is the most commercially interesting differentiator, because it attacks a real pain point: scaling speed without losing the value core.

5. Schema/data separation as a business principle. Few people formulate this explicitly. Most methodologies are either fully open (all SOPs are public) or fully closed (everything is a trade secret). Orgschema separates them: the parameter structure is publishable, the values are the moat. This is closer to the open-source-core + proprietary-data model that AI companies currently exploit. Transferring this model to operations is a careful move, though not a revolution.

6. Specification-transmission mechanism as the explanation for why functional departments exist at all. This is now a theoretical claim, not a methodological one. Mintzberg and Galbraith explain organisational structure through contingency factors (size, technology, environment). Orgschema offers an information-geometric explanation: departments minimise loss in transmitting the specification from top to bottom. If this is formally provable in the Projection Paper, it is a new contribution to organisation design theory. The work is currently in working-paper status, so it is too early to declare the move a success — but the swing is honest.

What Pretends to Be New in Orgschema and Is Not

There is a list of things in orgschema that look like contributions but, on inspection, are not. I am stating them out loud because the alternative is for a reviewer to find them and use them against the framework.

“Customer experience first” is not new. It is Customer Development. “YAML and git for business” is not, in essence, new. It is a transfer of IaC practices, and the author admits as much in the Prior Art section. “Tests for processes” is partly covered by BDD and by compliance-as-code (Open Policy Agent, Rego). Metaphors like “wave-particle duality of business” and “spectral interference” are rhetorical decoration, not substantive contributions. For a CFO or a COO they hinder more than they help. In this article I have used none of them, and the table above does not need any of them.

The Honest One-Sentence Differentiator

If I had to compress the whole comparison into a single sentence I could defend in a venture conversation, it would be this:

Orgschema is the first attempt to build a single versioned contract between customer experience, processes, executors, and suppliers, where compliance between levels is checked machine-by-machine and continuously, rather than documented in prose and audited once a year. “From the customer” is not the differentiator. The differentiator is that the chain from customer to supplier lives in one format and runs through one CI pipeline.

Everything else — the metaphors, the perceptual dimensions, the wave-particle duality — is rhetorical packaging. It is currently doing more harm than good, and the table above does not need it.

Where Orgschema Is Not Yet Honest Enough

I want to flag two qualifications that the table cannot communicate. They matter more than any of the differentiators above.

First, bundling is not always better than specialisation. The strength of BDD is precisely that it does not try to describe suppliers and perception; that is why its tools (Cucumber, SpecFlow) have been polished to an edge over fifteen years. The strength of BPMN is that it does not handle the customer experience; that is why Camunda, Signavio, and enterprise execution engines exist for it. Each neighbouring methodology has won because of narrow focus. Orgschema, by bundling twelve properties, runs the risk of becoming “average at everything and best at nothing.” Only practice will answer this question.

Second, a filled cell does not mean the property works in industry. “Waste detection” in orgschema is a line in the CI/CD validator. Whether it actually finds dead processes in a 500-employee company is unknown, because no such case is public yet. The same applies to “observer-agnostic,” “forkability,” and “schema/data separation”: these are design properties demonstrated on a six-product coffee shop. The honest reading of the orgschema column is “by design yes, by actual deployment — currently proof-of-concept.”

Block Has Already Built Part of the Architecture

There is one piece of evidence that the bundling claim is pointing at something real. On 31 March 2026, Jack Dorsey and Roelof Botha published “From Hierarchy to Intelligence“ — a description of how Block ($40B public company, operating Square, Cash App, Afterpay) eliminated approximately 4,000 of its 10,000 employees, specifically the middle-management layer, and replaced it with an AI-maintained “world model.”

I wrote a separate piece on the structural mapping. The short version is: Block independently built four of orgschema’s six layers, from engineering practice rather than from organisational theory, and called them by different names. Capabilities = L1-L2. Company World Model = L0. Customer World Model = demand-side specification. Intelligence Layer = L3-L4. Interfaces = L5.

The convergence is structural, not vocabulary. When a $40 billion company independently builds an architecture that a research programme formalises as its central theoretical claim, the claim is probably pointing at something real. Block does not yet have the verification layer (acceptance testing of the world model itself), and that is exactly the construct the article above identifies as the missing piece. Adding it is the next step the architecture generates on its own.

The Block convergence is not proof that orgschema works at industrial scale. It is proof that the structural pattern orgschema describes is being arrived at independently from production pressure. That is a stronger signal than any number of references to academic papers.

Where We Go From Here

The honest position is this: the structural claim is defensible, the table is reproducible, the convergence with Block is real, and the working papers carry the formal arguments. What is missing is industrial validation on cases more complex than a six-product coffee shop. We are looking for early adopters — operators who want to specify their business as a versioned contract, generate the test suite, and run it through a CI pipeline. Not in slide decks. In production.

If you are the COO of a multi-location operation that has hit the second-location problem (the previous article describes it), or a regulated business that is tired of spending money preparing for the next ISO audit, or a brand owner who has noticed that AI agents now mediate purchasing decisions and your specification is currently a PDF — then we have something to talk about.

The matrix above sets the conversation on a checkable footing. If your methodology of choice fills more than six cells, please tell me which one and which cells. If your methodology is one of the six in the columns and you think the table misrepresents it, please say where. Either correction is more useful than another article about why the customer matters.

This article is part of the Organizational Schema Theory series.

Reference implementation: Spectra Coffee on GitHub
Research papers: Zenodo community
Companion piece on Block: Block Just Built What We Theorized
Brand-strategy companion: Blue Ocean in Eight Dimensions — the same intellectual move (comparison table + honest contour disclaimer + “the bundling is the contribution”) applied on the strategy-frameworks side. C6 compares Blue Ocean, JTBD, Lean Startup, Porter, and RBV against SBT’s eight perception dimensions; this article compares BDD, BPMN, ISO 9001, IaC, Service Blueprint, and OKR/SLO against orgschema’s twelve cascade properties. The two essays are deliberate companions: the strategy half and the operations half of the same observation.

AI engineers discovered something counterintuitive: you cannot make a better coding agent by improving the model. You make it better by improving the environment. The constraints, the tools, the feedback loops, the test suites — the harness — determines performance more than the agent’s raw capability.

The same principle applies to your business. And it is the core insight behind orgschema.

The harness engineering parallel

In AI agent development, a “harness” is the environment in which an AI agent operates: the tools it can call, the constraints it must follow, the tests that validate its output, the feedback it receives. The field of harness engineering — designing these environments for maximum agent performance — has emerged as the critical discipline in building reliable AI systems.

The key findings from harness engineering research translate directly to organizational design:

Constraints improve performance. An AI agent with unlimited freedom produces worse results than one with well-designed constraints. The constraints are not limitations — they are the specification of what “good” looks like. A coding agent that must pass unit tests before merging produces better code than one that operates without tests. A barista who must satisfy a quality gate (extraction 25-30 seconds) produces better espresso than one with total freedom.

Environment design beats agent optimization. You can spend months improving the model (training a better barista, hiring more talented staff) and get marginal gains. Or you can improve the environment (better equipment, clearer specifications, tighter feedback loops) and get structural gains. The environment is the leverage point, not the agent.

Tests drive quality, not instructions. Telling an AI agent “write good code” produces mediocre results. Giving it a test suite and saying “make these pass” produces excellent results. Telling a barista “make good coffee” produces inconsistent results. Giving them a quality gate and saying “hit 25-30 seconds extraction with this dose” produces consistent results. Tests are more effective than instructions because they are verifiable.

Feedback loops must be tight. An AI agent that learns from production failures improves slowly and expensively. An AI agent that gets test results in seconds improves rapidly and cheaply. A business that discovers quality problems from customer complaints improves slowly. A business that validates operations against contracts on every commit improves continuously.

AI agent harness versus employee in orgschema: parallel structure of context, task definition, execution, quality gates, and traceability.

The reasoning sandwich

Harness engineering uses a pattern called the “reasoning sandwich”: invest heavily in planning (before execution) and verification (after execution), but let the execution itself be flexible. The agent can choose how to implement, but it must plan against the specification and verify against the tests.

Orgschema’s TDD cascade is a reasoning sandwich for business:

Planning (top-down specification): L0 customer experience contracts define the desired outcome. L1 signal requirements define what must be emitted. L2 process contracts define what must be achieved. This is the planning layer — invest heavily here.

Execution (flexible implementation): L3 procedures are how the contracts are implemented. Different executors (human, machine, hybrid) can implement the same contracts differently. Different locations can implement differently. The execution is flexible — the implementation is the executor’s domain.

Verification (continuous validation): The CI/CD pipeline validates that execution satisfies the contracts. The spectral profile measurement validates that the customer experiences the intended perception. This is the verification layer — invest heavily here.

The middle layer (execution) gets freedom. The outer layers (planning and verification) get investment. This is exactly the harness engineering pattern, applied to organizational design.

What AI agents and employees have in common

The parallel is not metaphorical. AI agents and human employees face the same fundamental challenge: executing tasks in a complex environment with incomplete information, competing priorities, and the need for consistent quality.

In both cases, the quality of the output depends more on the quality of the specification and the tightness of the feedback loop than on the raw capability of the agent.

A brilliant barista in a poorly specified environment (no quality gates, no traceability, no validation) will produce inconsistent results because there is no feedback mechanism to maintain quality. An average barista in a well-specified environment (clear contracts, daily calibration, continuous validation) will produce consistent results because the harness maintains quality.

This is not an argument against talent. It is an argument about leverage. Invest in both the agent and the environment, but understand that the environment has higher leverage.

Stabilization and growing autonomy

In harness engineering, new AI agents start with tight constraints and gradually receive more autonomy as they demonstrate competence. The first tasks are simple, heavily guided, with strict validation. As the agent builds a track record, constraints relax and the agent operates with more independence.

Orgschema’s maturity model (M0 through M5) follows the same pattern:

M0 (Tribal knowledge): No specification. The “agent” (employee) operates on memory and habit. No constraints, no tests, no validation. Maximum freedom, minimum consistency.

M1 (Schema): The specification structure exists but values are incomplete. The employee knows what should be measured, even if not all measurements are in place. Some constraints, no automated tests.

M2 (Contracts): Quality gates are defined. The employee knows what must be achieved. The CI/CD pipeline validates contracts. Constraints are clear, tests run automatically.

M3 (Procedures): Implementation is documented. The employee has both the “what” (contracts) and the “how” (procedures). But the procedures are guidance, not prison — the contracts are the binding constraint, and the employee can adapt the procedure as long as the contract passes.

M4 (Traced): Full traceability from every parameter to its customer experience justification. The employee understands not just what and how, but why. This understanding enables informed deviation — choosing to exceed the contract in ways that serve the experience goal even when the specification does not explicitly call for it.

M5 (Validated): Continuous measurement closes the loop. The spectral profile validates that the entire chain — from specification through execution to perception — is working. The harness is complete.

The progression from M0 to M5 is a growing autonomy pattern: start with specification (constraints), add validation (tests), add traceability (understanding), add measurement (feedback). At each level, the employee has more context and more freedom to exercise judgment — because the harness provides the safety net that makes freedom productive rather than risky.

The environment design priority

Harness engineering research consistently shows that improving the environment yields higher returns than improving the agent, up to a point. The same holds for organizations:

Equipment investment (L4 inputs): a better grinder produces more consistent extraction than more barista training. The equipment is the harness; the barista is the agent. Invest in the harness first.

Specification investment (L2 contracts): clear quality gates produce more consistent output than vague instructions. “Extraction 25-30 seconds” is a better harness than “make it taste good.” Invest in the specification.

Feedback investment (CI/CD validation): automated quality checking catches more issues than periodic audits. Continuous validation is a tighter feedback loop than quarterly reviews. Invest in the feedback mechanism.

Training investment (agent improvement): once the harness is good, training has higher marginal returns. A barista who understands the contracts, works with calibrated equipment, and receives continuous feedback improves faster than one trained in a chaotic environment. Train the agent last, not first.

This is not the conventional wisdom. Conventional management prioritizes people: “hire great people and get out of their way.” Harness engineering suggests: “design a great environment and put people in it.” Both matter. But the environment has higher leverage because it affects every agent simultaneously and permanently, while training affects one agent at a time and decays over time.

The AI agent connection

Orgschema’s specifications are not just for human employees. They are natively readable by AI agents. An LLM can traverse the TDD cascade, answer questions about any parameter, trace traceability chains, and even propose specification changes.

This creates a unique convergence: the same specification (the harness) serves both human employees and AI agents. The human barista reads the quality gate and uses judgment to exceed it. The AI agent reads the quality gate and validates that it is met. Both operate within the same specification. Both benefit from the same constraints.

As AI agents become more capable in physical-world tasks (robotic coffee preparation, automated inventory management, dynamic pricing), the orgschema specification becomes the shared operating environment for human and AI agents working side by side. The human handles the social dimension, the craft premium, the judgment calls. The AI handles the consistency validation, the data analysis, the compliance checking. Both reference the same specification.

Harness engineering for AI and orgschema for business are not parallel developments. They are the same development, applied to different agent types, using the same design principles. Constraints improve performance. Environment beats agent. Tests beat instructions. Feedback loops must be tight.

The discipline that AI engineers discovered for making coding agents reliable is the same discipline that makes coffee shops consistent. The harness is the specification. The specification is the harness.

This article is part of the convergence series bridging Spectral Brand Theory (perception measurement) and Organizational Schema Theory (operational specification).

SBT research paper: Zenodo preprint
OST research paper: Zenodo preprint
Open-source toolkits: SBT · Orgschema

Our last consulting engagement delivered 142 slides. The client implemented 3 of the recommendations. The other 139 slides sit in a SharePoint folder that nobody has opened since the final presentation. The engagement cost $180,000. The implemented value was maybe $30,000.

This is not unusual. McKinsey’s own research suggests that 70% of transformation programs fail to achieve their goals. The slide deck is part of why.

The deliverable problem

A consulting engagement follows a predictable arc: discover, analyze, recommend, present. The consultants spend weeks interviewing employees, mapping processes, analyzing data, and benchmarking. They synthesize their findings into a slide deck with frameworks, matrices, and recommendations. The client receives the deck, nods through the presentation, and begins the work of translating recommendations into operational changes.

That translation is where value is lost. The slide deck describes what should change. It does not encode what should change in a format that the organization’s systems can consume, validate, or track. “Improve extraction consistency” is a recommendation. “extraction_time_seconds: [25, 30], validated on every commit” is a testable specification.

The gap between recommendation and specification is where 70% of transformation value disappears.

Consulting deliverable evolution: static PowerPoint deck versus living, validated, forkable git repository.

The specification as deliverable

What if the consulting engagement delivered an orgschema repository instead of a slide deck?

The discovery phase stays the same: interviews, observation, process mapping. But instead of synthesizing into slides, the consultant synthesizes into specifications:

L0 (Customer Experience Contracts): “Here are the experience goals your business should achieve, based on our analysis of your customer base, competitive position, and strategic intent.”

L1 (Signal Requirements): “Here are the signals your business must emit to produce those experiences, mapped across eight perceptual dimensions.”

L2 (Process Contracts): “Here are the quality gates your processes must meet to emit those signals. These are testable. Your CI/CD pipeline will validate them.”

L3-L5 (Procedures, Inputs, Sourcing): “Here is how your current operations implement those contracts, with gaps flagged where current practice does not satisfy the specification.”

The deliverable is not a document about the business. It is a testable specification OF the business. The client does not need to translate recommendations into operational changes. The operational changes ARE the specification.

What changes for the consultant

Higher-value deliverables. A slide deck is an opinion. A test suite is a validated specification. The test suite is harder to produce (it requires precise, testable assertions rather than directional recommendations) and more valuable to the client (it integrates directly into operations). Higher difficulty and higher value justify premium pricing.

Verifiable implementation. The slide deck engagement ends with a presentation. Implementation is the client’s problem. The test suite engagement ends with a git push of a passing specification. Follow-up engagements are git diff reviews: “Here is what changed since our last engagement. These three contracts are failing. These two procedures drifted from specification.”

The consultant can measure their own impact: how many of the specified contracts are being met six months later? The git log shows exactly which specifications were maintained and which were abandoned. This is uncomfortable for consultants who prefer the ambiguity of “we recommended and they didn’t implement.” It is valuable for consultants who want to demonstrate measurable impact.

Reusable frameworks. A slide deck is customized for each client. An orgschema specification can be partially reused. The L0-L2 contracts for a specialty coffee operation are largely transferable across clients in the same industry. The consultant maintains a library of validated test suites that accelerate new engagements.

This is the consulting equivalent of code reuse. Instead of building every engagement from scratch, the consultant forks a prior client’s specification (anonymized, with client permission), customizes it for the new context, and focuses the engagement on the gaps rather than the entirety.

LLM-enhanced delivery. When the deliverable is a structured specification, the client can query it with an LLM: “What happens to our margin if we switch to this supplier?” “Which experience goals are at risk if we reduce staff by one person per shift?” “What is our compliance status for the new allergen regulation?”

The specification becomes a living consultant — not replacing human judgment, but making the consultant’s knowledge queryable long after the engagement ends.

What changes for the client

No translation gap. The deliverable integrates into operations directly. There is no “now we need to figure out how to implement the recommendations” phase. The recommendations ARE the specifications. Implementation is running the operations to pass the tests.

Measurable progress. Implementation tracking shifts from “we had a steering committee meeting and it went well” to “14 of 18 contracts are passing, 3 are in progress, 1 has been deprioritized.” The CI/CD pipeline provides objective, continuous progress measurement.

Preserved knowledge. When the consulting engagement ends, the knowledge stays in the repository. It does not evaporate as the consultant’s slides age on SharePoint. The specification is version-controlled, queryable, and maintained as a living document.

Cheaper follow-ups. The second engagement does not start from scratch. The consultant runs the existing test suite, reviews the git diff since the last engagement, and focuses on failures, gaps, and new requirements. The discovery phase shrinks from weeks to days because the baseline is already specified.

The engagement model

An orgschema consulting engagement follows this structure:

Phase 1: Characterization (1-2 weeks). Audit current operations. Write characterization tests — specifications that document what the business currently does, not what it should do. This captures the baseline truthfully, including inconsistencies and gaps. The characterization tests are the “before” state.

Phase 2: Specification (2-3 weeks). Design the target state. Write L0 experience contracts based on strategic goals. Derive L1 signal requirements and L2 process contracts. Identify gaps between characterization tests and target contracts. These gaps ARE the consulting recommendations, expressed as failing tests.

Phase 3: Implementation Planning (1 week). For each failing test, specify what needs to change at L3-L5 to make it pass. Estimate effort, cost, and timeline. Prioritize by impact on L0 experience goals.

Phase 4: Delivery. git push the target specification to the client’s repository. Walk through the failing tests. Explain the traceability from each recommendation (failing test) to the customer experience goal it serves. The client sees exactly what needs to change and why.

Phase 5: Follow-up (ongoing, optional). Monthly or quarterly git diff review. Which tests are now passing? Which are still failing? What new requirements have emerged? The follow-up is focused and efficient because the test suite provides the agenda.

The uncomfortable truth

Some consultants will resist this model because it makes their recommendations falsifiable. A slide that says “improve customer experience through enhanced barista training” cannot be tested. A contract that says barista_knowledge_test: origin_accuracy > 80% can be tested, and might fail, and that failure is visible.

But falsifiability is precisely what makes the deliverable valuable. A recommendation that cannot be verified is an opinion. A specification that can be validated is a tool. The client is paying for tools, not opinions — even if the consulting industry has historically sold opinions packaged in beautiful slides.

The consulting firm that delivers repos instead of decks will win the clients who care about implementation, not just advice. Those are the clients worth having.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

Harvard Business School sells case studies for $15 each. The student reads 20 pages about a company that made a decision five years ago. The class discusses what they would have done differently. The professor guides the conversation. Nobody tests their theory.

What if the case study were a git repository? What if “what would you have done differently?” were answered by making the change, running the test suite, and seeing which customer experience goals break?

The case method’s limitation

The HBS case method, invented in 1921, is the dominant pedagogy in management education. Students read a narrative about a business situation, analyze the decision, and discuss alternatives in class. It is excellent for developing judgment, argumentation, and pattern recognition.

It is terrible for testing consequences.

When a student says “I would have expanded to a second location sooner,” there is no way to validate that claim. The case provides a narrative, not a model. The student’s recommendation is an untested assertion, evaluated by the professor’s judgment and the class’s reaction, not by the operational reality of the business.

Business simulation games (Capsim, Marketplace, Cesim) attempt to address this. Students make decisions in a simulated business environment and observe outcomes. But these simulations are purpose-built, expensive ($14-107 per student per simulation), and abstract. The simulation’s model of reality is hidden. Students learn to optimize within the simulation’s rules, which may or may not correspond to real operational dynamics.

The forkable case study

An orgschema demonstration is already a complete teaching case. The Spectra Coffee demo contains 25 YAML specification files covering a complete coffee operation: 6 products, 4 process types, 2 compliance frameworks, perception contracts across 8 dimensions, and a CI/CD pipeline that validates the whole cascade.

A student can clone this repository in 30 seconds. Then the exercises begin:

Exercise 1: Location Fork. “Open Spectra Coffee in your home city. Which L5 sourcing parameters change? Which L4 inputs change? Do the L2 process contracts still pass with your local suppliers? Run the pipeline and find out.”

The student forks the repo, modifies the sourcing and input files for their local context (different water quality, different supplier availability, different rental costs), and runs the validator. If a supplier cannot provide direct-trade certification, the signal requirement for “ideological.ethical_sourcing” fails. The student sees the consequence: not as a narrative outcome in a case discussion, but as a failing test with a traceable chain to the customer experience impact.

Exercise 2: Competitive Response. “A competitor opens next door with lower prices and faster service. Modify the L0 customer experience contract to respond. Which L1 signal requirements change? Which L2 process contracts need updating? What is the cost impact?”

The student adjusts the experience targets — perhaps increasing the speed target or adding a price-value signal. The cascade propagates: new signal requirements demand new process contracts, which may require new equipment (L4) or different suppliers (L5). The cost of competitive response becomes visible as a chain of specification changes, not as a vague strategic recommendation.

Exercise 3: Supplier Crisis. “Your coffee bean supplier raises prices 20%. Change the L5 sourcing specification. Trace the impact through L4 inputs to L2 process contracts to L0 experience goals. Can you maintain the customer experience contract with the cost increase? What breaks?”

This exercise teaches supply chain impact analysis as cascade traversal. The student modifies one parameter and watches the effects propagate. The margin calculations change. The cost-of-goods specification may violate the pricing contract. The student must decide: absorb the cost (reduce margin), pass it to the customer (risk the economic dimension of experience), or find an alternative supplier (different L5 that still satisfies L4 requirements).

Exercise 4: Regulation Change. “A new allergen regulation passes requiring declaration of sesame as a 15th allergen. Add the constraint contract. Run the pipeline. Which products fail? Which processes need updating?”

The student adds a regulatory requirement as an L0 constraint contract and discovers which products lack sesame assessment, which processes need modified allergen management procedures, and which supplier specifications need updated documentation. The regulatory impact analysis takes minutes, not the weeks it would take in a real organization with Word-based documentation.

Exercise 5: Scale. “Expand to three locations. Define which contracts are shared (the test suite) and which implementations are location-specific. Design the fork strategy.”

This exercise teaches the most important lesson in multi-unit operations: what is the test (shared) and what is the implementation (local). The student designs an organizational architecture by deciding which specification levels are shared and which are overridden.

Why this is better than simulations

Business simulations are black boxes. The model that determines outcomes is hidden from students. When a student makes a pricing decision in Capsim and revenues decline, the causal chain is opaque. The student learns that the decision was “wrong” but not why, in operational terms, it failed.

Orgschema cases are glass boxes. The specification IS the model. Every parameter is visible. Every traceability chain is explicit. When the student’s change causes a test failure, the cascade shows exactly which contracts are violated and why. The learning is structural, not statistical.

The AI integration deserves emphasis. A student working with an orgschema case can ask an LLM: “What happens to the allergen declarations if I switch from cow’s milk to oat milk in the cappuccino?” The LLM traverses the TDD cascade — checks the ingredient specification, the allergen matrix, the cross-contamination risks, the signal requirements, the constraint contracts — and returns a specific answer with traceability. This is not a chatbot. It is an operational analyst that understands the business’s test suite.

The teaching workflow

An orgschema teaching module follows this structure:

Lecture (30 minutes): Introduce the TDD cascade. Explain the six levels. Show how customer experience contracts (L0) propagate to sourcing (L5). Use the Spectra Coffee demo as the running example.

Lab (90 minutes): Students fork the demo repository. Each student or team receives an exercise (location fork, competitive response, supplier crisis, regulation change, or scale). They modify specifications, run the validator, and prepare a brief presentation of their findings.

Discussion (30 minutes): Teams present their changes and test results. The class discusses: Which tests failed? Why? What were the trade-offs? Was the student’s response optimal? How would they iterate?

Assessment: The student’s modified repository IS the deliverable. The professor reviews the git diff, the test results, and the traceability of the changes. Grading is partially automatable — did the student’s modifications pass the relevant tests? Did they maintain traceability? Did they introduce new tests where needed?

This workflow replaces the “read, discuss, write a memo” cycle with “fork, modify, test, present.” The student’s engagement is active, not passive. The feedback is structural, not subjective. The deliverable is a repository, not an essay.

The cost advantage

Harvard Business Publishing generates approximately $200 million annually from case study sales. A typical MBA program uses 300-500 cases over two years at $15 each, plus textbooks and simulation licenses. The pedagogical infrastructure for management education is expensive.

Orgschema cases are free. The repository is open source. The validator is open source. The only cost is an LLM subscription for the AI-assisted exercises (approximately $20/month per student). A complete operational case study with testable exercises, CI/CD validation, and AI integration costs less than two HBS cases.

This is not an argument against HBS cases, which develop judgment and argumentation skills that specification manipulation does not. It is an argument for adding orgschema cases to the curriculum as a complement — teaching operational specification alongside strategic analysis.

What faculty need

For management educators interested in piloting orgschema cases:

1. Start with the demo. Clone orgschema-demo. Read the README. Explore the TDD cascade from L0 to L5. This takes 30 minutes.

2. Design one exercise. Pick the exercise type that fits your course: location fork for international business, supplier crisis for operations management, regulation change for compliance courses, competitive response for strategy.

3. Test the LLM integration. Ask an LLM to answer questions about the specification. “What is the margin on espresso if the bean cost increases 15%?” “Which processes would change if we switched to automated espresso machines?” Verify that the LLM can traverse the cascade accurately.

4. Pilot with one section. Run the orgschema lab alongside your regular case discussion. Compare student engagement and learning outcomes.

The Spectra Coffee demo was confirmed as a suitable teaching case by an independent academic reviewer during the evaluation panel (who noted it was “more interesting than most cases I read in business school”). The specification is rich enough for graduate-level analysis while accessible enough for undergraduate operations courses.

The business school of the future teaches students to fork, modify, test, and defend their operational decisions against a validation pipeline. The case study of the future is a git repository.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

On March 31, 2026, Jack Dorsey and Sequoia partner Roelof Botha published “From Hierarchy to Intelligence“. Block, a $40 billion public company operating Square, Cash App, and Afterpay, described how it eliminated roughly 4,000 of its 10,000 employees — specifically the middle management layer — and replaced it with an AI-maintained “world model.”

This is not a business trend piece about AI restructuring. It is something more specific: a large company independently building the organizational architecture that Organizational Schema Theory formalizes as its central claim. Not a loose analogy, not a surface resemblance — a structural match, arrived at from engineering practice rather than organizational theory.

The convergence is worth examining carefully: what Block got right, what the architecture implies, and the one construct the essay does not describe that will determine whether this model holds.

What Dorsey and Botha Published

The essay opens with a history of hierarchical coordination that reads, accurately, as two thousand years of humans serving as information-routing infrastructure. Roman contubernium structure, Prussian General Staff, McCallum’s railroad org chart, Taylor’s functional pyramid: each iteration improved the routing protocol without questioning whether the router had to be human.

Block’s answer is that it does not. The proposed architecture has four components.

Capabilities are atomic financial primitives — payments, lending, card issuance, banking, buy-now-pay-later, payroll. They have no user interfaces. They have reliability, compliance, and performance targets. They are building blocks, not products.

World Models — the essay uses the plural — have two sides. The Company World Model is how Block understands its own operations, performance, and priorities: the information that used to flow through management layers, now maintained continuously by AI from the machine-readable artifacts a remote-first company already produces. The Customer World Model is a per-customer, per-merchant representation built from transaction data — what Dorsey calls “the most honest signal in the world,” because spending behavior cannot be faked the way survey responses can.

The Intelligence Layer composes capabilities into solutions for specific customers at specific moments. The essay gives two worked examples: a restaurant with tightening cash flow receives a composed loan-plus-repayment-adjustment before it thinks to ask; a Cash App user showing relocation signals receives a composed banking setup calibrated to a new city. No product manager decided to build either solution. The capabilities existed; the intelligence layer recognized the moment and assembled them.

Interfaces — Square, Cash App, Afterpay, TIDAL, Bitkey, Proto — are delivery surfaces. They matter for user experience, but, as the essay states explicitly, the value is in the model and the intelligence, not the interface.

The organizational structure collapses to three roles: individual contributors (ICs) who build and operate the system’s layers; Directly Responsible Individuals (DRIs) who own cross-cutting problems for defined periods, typically 90 days, with authority to pull resources across teams; and player-coaches who combine building with developing people. There is no permanent middle management. The world model handles alignment. The DRI structure handles prioritization. The player-coach handles craft and people development.

The Structural Mapping to OST

Organizational Schema Theory models any production organization as a six-level specification cascade. Each level provides formal constraints that make the levels below tractable. The levels run from purpose and values (L0-L1) through policies, procedures, and input specifications (L2-L4) to sourcing and execution (L5). The core claim is that organizational failures are predominantly specification failures — not execution failures — and that the specification must precede the implementation.

Block’s four-component architecture maps onto this cascade with striking precision.

The most important cell in that table is the Company World Model mapped to L0. OST’s L0 is the organizational specification: the formal, machine-readable representation of what an organization is, what it produces, and how it operates. That is precisely what Block is building. Dorsey describes it as replacing “the information that used to flow through layers of management” — but this understates what the world model actually is. It is not just information flow. It is a maintained, continuously updated specification of the organization itself.

Middle management, in this framing, was always a human approximation of a specification. Managers held in memory what the organization was doing, what it had decided, what constraints were active, what resources were available. They transmitted that knowledge imperfectly, at human speed, with human cognitive limits and human political incentives distorting the signal at every relay. The world model replaces the approximation with something more reliable: a specification that is explicit, machine-readable, and continuously updated from primary data sources rather than from human summaries of primary data sources.

The DRI model is also a specification construct, though the essay does not use that language. A DRI owns a specific problem for a defined period. The problem scope is specified, the ownership is specified, the time boundary is specified. This is not assignment — it is a bounded specification of a problem-solving contract. The 90-day limit is particularly significant: it prevents the permanent accumulation of organizational territory that makes traditional middle management resistant to change.

The customer world model, built from transaction data as “honest signal,” is the demand-side specification: the formal representation of what customers actually do rather than what they say they want. OST’s framework distinguishes between the organizational specification (what the company intends to produce) and the demand-side specification (what the customer actually needs). Most organizational failures occur in the gap between these two. Block is building both simultaneously, from the same data infrastructure, which is the correct architecture.

What Block Gets Right

Block’s essay makes several claims that align precisely with OST’s theoretical framework, without using OST’s vocabulary.

The essay’s central thesis — that “the coordination layer is a specification problem, not a people problem” — is stated implicitly but is the logical foundation of the entire architecture. Hierarchy existed because coordination required human information routing. Remove the information-routing constraint and hierarchy becomes optional. The world model does not replace people; it replaces the coordination function that hierarchy was performing on people’s behalf.

Transaction data as “honest signal” operationalizes a key OST principle: the most reliable specification source is operational metadata — what the system actually does, not what participants report about what it does. Surveys, roadmaps, management summaries, and strategy documents are all derived representations. Transaction records are primary. Building the customer world model from transaction data rather than survey data is not just a data quality decision; it is an architectural commitment to specification accuracy.

The failure mode that the intelligence layer exposes when it cannot compose a solution is the most theoretically interesting element of the essay. Dorsey writes: “When the intelligence layer tries to compose a solution and can’t because the capability doesn’t exist, that failure signal is the future roadmap.” In OST terms, this is specification gap detection driving development. The intelligence layer is continuously running against the capability layer. Gaps produce failure signals. Failure signals become development priorities. The specification — the world model’s representation of what customers need — generates the backlog directly from incompleteness rather than from product manager hypotheses. This is a formal feedback loop between specification and implementation.

Player-coaches who still build are specification-aware practitioners. The essay’s insistence that player-coaches continue doing technical work is not just a cultural preference; it maintains the coupling between the people who shape the specification and the people who understand what the specification actually requires to implement. Pure managers, in OST’s framing, are specification-blind: they hold organizational territory without maintaining operational understanding of the specification constraints that territory implies.

What Block Is Missing

Every domain that operates on formal specifications has, over time, developed acceptance testing: a verification mechanism that answers the question “is the specification correct?”

Engineering uses tolerance inspection and load testing. Software uses continuous integration and test-driven development. Medicine uses clinical trial endpoints and regulatory review. Scientific publishing uses peer review. Legal practice uses precedent and appellate review. Accounting uses audit. Each domain learned the same lesson through its own failure modes: executing a specification reliably is not enough. The specification itself must be verified before — and continuously during — execution.

Block’s essay describes a sophisticated specification architecture. What it does not describe is a verification mechanism for the specification.

The Company World Model is continuously updated from machine-readable organizational artifacts. But who tests whether it accurately represents the organization? The Customer World Model is built from transaction data. But transaction data captures what customers do within the current product surface — it cannot, by construction, capture what customers would do if the product surface were different, or what customers need but cannot currently express through available transactions. The world model is an outstanding instrument for representing revealed behavior. It is not, on its own, an instrument for detecting its own blind spots.

The DRI model partially addresses this at the problem-solving level. A DRI owns a problem for 90 days and is accountable for whether the problem was solved — which tests the outcome (was the customer behavior affected as intended?) but does not test the specification (was the world model’s representation of the problem accurate in the first place?). Outcome testing and specification testing are structurally distinct. A DRI who achieves their 90-day target has demonstrated that the solution worked; they have not demonstrated that the problem was correctly specified before the solution was built.

This is not a minor gap. It is the same failure mode that traditional hierarchy exhibited, operating at higher speed and with lower visibility. Hierarchical organizations misrepresented reality through lossy information routing — managers simplified, filtered, and distorted signals as they transmitted them up the chain. The world model eliminates the lossy human relay, but it substitutes a different distortion: the world model can only represent what its training data allows it to represent. Specification errors that are consistent with the training data will not produce failure signals. They will produce plausible-looking outputs that are systematically wrong in ways the system cannot detect from the inside.

The Roman army this essay opens with learned exactly this lesson. A Roman legate had no verification mechanism for the intelligence his centurions relayed. A centurion who consistently misreported enemy strength would not generate an internal failure signal until the battle went wrong. The centurion was the specification. The battle was the acceptance test.

Block’s intelligence layer composes solutions. The question it cannot yet answer is: how do you know the world model is right? Who tests the specification?

Why Independent Convergence Matters

Block arrived at this architecture from engineering practice. Dorsey and Botha did not read OST. They built a product company at scale and discovered, through operational pressure, that the bottleneck was not execution capacity but specification accuracy. The middle management layer was not producing enough coordination value relative to its cost in information distortion and organizational inertia. The world model is what replaced it.

When a $40 billion company independently builds an architecture that a research program formalizes as its central theoretical claim, the claim is probably pointing at something real. Independent convergence from practice is stronger validation than replication from theory, because the practitioner has no incentive to fit the evidence to the framework.

The convergence is in the structure, not the vocabulary. Dorsey says “world model” and “intelligence layer”; OST says “organizational specification” and “orchestration layer.” The terminological difference is unimportant. The structural equivalence is: both frameworks identify the organization’s representation of itself and its customers as the central coordination artifact, both identify the composition of atomic capabilities as the production mechanism, and both identify delivery surfaces as the implementation layer where value becomes perceptible.

The point where the frameworks diverge is the point where OST has something to add. The acceptance testing construct — formal verification of the specification itself, not just verification of the outputs the specification produces — is the construct Block’s architecture does not yet include. It is also the construct that every other specification-based domain developed after it discovered the failure mode of unverified specification. Block is now operating a production-grade organizational specification. The next question the architecture generates is: what is the test suite for the world model?

Closing

The question that Block’s essay raises is not whether AI can replace middle management. Block has demonstrated that it can perform the information-routing function middle management was performing. The question that the architecture generates next is whether companies will build the verification infrastructure that makes the replacement reliable.

Block has the specification. The world model is real, continuously updated, and built from honest signal. The intelligence layer is composing solutions from atomic capabilities in ways no product manager designed. The three-role structure has eliminated the coordination overhead of permanent middle management.

What Block needs next is acceptance testing: a formal mechanism for verifying that the specification is accurate, not just that the specification is internally consistent and produces outputs that match its own predictions. The distinction between those two is the distinction between a system that works and a system that knows when it is wrong.

Every domain that has successfully operated on formal specifications has solved this problem. Organizational design is the domain that has consistently deferred it. Block has just demonstrated why it can no longer be deferred.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

Science has a production problem it refuses to name.

Every software team knows what happens when you ship code without a test suite. Every manufacturing operation knows what happens when you remove the quality control gate. The defects accumulate silently. The failures arrive unpredictably. The cost of fixing them compounds because nobody specified what “correct” meant before the work started.

Peer review is science’s production gate. It determines what knowledge gets published, what researchers get funded, what findings get cited. It is the single most consequential quality-control step in the entire scientific enterprise.

It has no specification.

No defined acceptance criteria. No traceability from reviewer judgment to editorial decision. No version control on evaluation standards. No regression testing to catch when the process drifts from its stated purpose. No systematic tracking of reviewer calibration over time.

In software engineering, this is deploying to production with no test suite. In manufacturing, it is shipping without quality control. No other industry would apply this level of informality to its most consequential process. Science has accepted it as normal because the alternative — specifying what “publishable knowledge” actually means before you evaluate whether a paper achieves it — turns out to be deeply uncomfortable.

The discomfort is informative.

The OST cascade applied to peer review

Organizational Schema Theory models any production process as a six-level specification cascade, where each level provides formal constraints that make the levels below it tractable. The cascade runs from purpose (L0) through values (L1), policies (L2), procedures (L3), input specifications (L4), and sourcing (L5). Each level inherits constraints from above and provides constraints for what lies below.

When you map peer review onto this cascade, the gaps become visible immediately.

L0: Purpose. The stated purpose of peer review is to advance reliable knowledge. But “reliable” is not defined operationally. Does it mean reproducible? Generalizable? Falsifiable? Novel? Relevant to which audience, on which timescale? Different editors and reviewers hold different implicit definitions of L0, and those definitions are never reconciled. The purpose is stated but not specified.

L1: Values. Peer review asserts principles: rigor, reproducibility, fairness, novelty, significance. These are listed in editorial mission statements and reviewer guidelines. They are also entirely non-testable as stated. “Rigorous” means different things to a statistician, a theorist, and a practitioner. “Novel” in a field moves fast means something different from “novel” in a field that moves slowly. L1 exists on paper but lacks the operational definitions that would make it enforceable.

L2: Policies. This is where peer review is actually specified. Editorial ethics policies, authorship requirements, conflict of interest disclosure, data availability statements, formatting guidelines — these are real, enforced, and relatively consistent across journals. Most journals have invested heavily at this level. L2 is, by the standards of the rest of the cascade, well-formed.

L3: Procedures. How are reviewers assigned? How are their reports weighted against each other? How does an editor adjudicate when three reviewers disagree? What happens when a reviewer’s assessment is internally inconsistent? These questions are answered differently in every journal, mostly by convention and editorial judgment. The gap between L2 (policy) and L3 (what actually happens in a given submission) is where most peer review failures originate. The policies specify intent; the procedures are ad hoc.

L4: Input specifications. Reviewer instructions are the specification for the human labor that produces the review. They typically ask reviewers to rate novelty, rigor, and significance on a 1-5 scale and to provide a recommendation. The rating scales are unvalidated. The dimensions are undefined. Different reviewers apply different internal calibrations to the same scale labels. A “3 for significance” from one reviewer and a “3 for significance” from another reviewer are not comparable measurements — they are personal judgments encoded in a format that implies false precision.

L5: Sourcing. Reviewer selection determines who evaluates what. It is conducted primarily through editor networks, author suggestions, and database searches. There is no systematic quality tracking. A reviewer who consistently rejects papers later validated by independent replication is indistinguishable in the system from a reviewer whose acceptances were later retracted. The sourcing level is entirely without feedback.

The result: L2 is specified. L0, L1, L3, L4, and L5 are either absent or ad hoc. The cascade has one robust level surrounded by assumptions.

What if peer review had acceptance tests?

The OST approach to any underspecified process starts from the same question: what are the acceptance criteria? Not preferences, not heuristics — testable criteria with explicit pass/fail thresholds.

For peer review, this means treating each claimed evaluation dimension as a measurement instrument that must be validated before being used.

If “reproducibility” is a review criterion, it needs an operational definition: does the paper provide sufficient methodological detail that a competent researcher in the field could replicate the key analyses? That question can be evaluated consistently across reviewers. It can be given a binary response rather than a five-point opinion scale. Disagreement between reviewers becomes a calibration signal rather than a nuisance to average away.

If “novelty” is a criterion, it needs a reference frame: novel relative to what literature, as of what date, as assessed by what search protocol? A reviewer who evaluates novelty without specifying the literature they searched cannot be calibrated against a reviewer who uses a different protocol.

The deeper implication is reviewer calibration as a measurable property. Every reviewer generates a record: papers they evaluated, recommendations they made, outcomes those papers eventually reached in terms of citation, replication, retraction, or follow-on validation. A reviewer whose rejections cluster among papers later validated by independent groups has different predictive validity from a reviewer whose rejections cluster among papers that were, in retrospect, methodologically weak. The current system collects this data implicitly and uses none of it.

This is not a theoretical proposal. Software engineering solved a structurally identical problem when it developed version control and continuous integration. The key insight was not that individual engineers are unreliable — it is that individual judgment without systematic feedback loops is structurally incapable of maintaining quality at scale. The solution was not to improve the engineers. It was to build the specification infrastructure that makes engineer quality measurable and improvable.

Peer review needs the same infrastructure.

The CI/CD analogy

Contemporary software development has moved from waterfall to continuous integration. The implications for how quality is defined, measured, and maintained are substantial.

Waterfall development works like traditional peer review: a long production process culminates in a single evaluation event that produces a binary outcome. Accepted or rejected. Published or not. The evaluation happens once, at the end, after all the work is complete. The feedback loop is long and the cost of failures is high.

Continuous integration works differently. Work is committed frequently to a shared repository. Each commit triggers automated tests. Problems are caught immediately, when they are small and cheap to fix, rather than accumulated until they are large and expensive to diagnose. The gate is not a single event but a continuous process.

Modern scientific practice has already reinvented the key steps of this pipeline, without yet connecting them.

Preprint servers function as commit. The work enters a shared repository before formal review. Early feedback is possible. The community can identify obvious errors before the review process begins.

Open review functions as pull request. When reviews are named, visible, and structured, the review process becomes a documented artifact rather than an opaque event. Disagreements are visible. The reasoning behind recommendations is preserved and can be evaluated independently of the outcome.

Editorial decision functions as merge. The formal acceptance decision, when it comes after a structured visible review, is a merge of reviewed work into the published record — with the review history attached.

Post-publication commentary functions as monitoring in production. Citations, critiques, and follow-on papers represent ongoing evaluation of whether the published work continues to be reliable.

Replication studies are regression tests. They check whether the findings hold under variations in protocol, sample, and context. A finding that fails replication is a regression — it worked in the original test environment and failed in a different one.

The pipeline exists. What it lacks is the specification cascade that connects the stages: the formal acceptance criteria that make pre-publication review consistent, the reviewer calibration tracking that makes the evaluation reliable, and the traceability between review assessments and downstream outcomes that makes the system improvable over time.

The specification gap in science is precisely what Organizational Schema Theory identifies in organizational design more broadly: the distance between what the system claims to do (ensure quality) and what it actually does (apply prestige heuristics, editorial intuition, and reviewer networks that are never validated against outcomes). The impossibility of exhaustive specification, formalized in the R5 paper’s coverage impossibility theorem, does not make specification futile — it makes specification choices consequential. Choosing which dimensions of quality to specify, and at what resolution, determines which failures the system can catch and which it will systematically miss.

Peer review has made its choices implicitly. The result is a system that catches formatting problems reliably and methodological irreproducibility unreliably.

Registered reports are TDD

The most significant methodological innovation in scientific publishing in the past decade is also the most underused: the registered report.

In a registered report, researchers submit a study design — hypothesis, method, planned analyses, power calculation — before collecting any data. The journal reviews and conditionally accepts the design. Data collection proceeds. The results are published regardless of what they are, because the quality decision was made before the results existed.

This is test-driven development.

TDD requires writing the test before writing the code. The test specifies what correct behavior looks like. The implementation is then evaluated against the test, not against the implementer’s judgment about whether the implementation looks good. The test was written when the implementer did not yet know what the implementation would produce — which means the test cannot be unconsciously tuned to the implementation’s actual behavior.

Registered reports apply exactly this logic. The hypothesis and method are the test. The data collection is the implementation. The review of the test happens before the implementation exists, which means the review cannot be biased by knowing the results. Novelty bias — the tendency to evaluate findings as more significant when the results are surprising — cannot operate on a design review because the results do not yet exist.

The resistance to registered reports is structural. Evaluating a design before seeing the results requires having specified acceptance criteria for designs, not just for findings. Most journals prefer to evaluate outputs after the fact. This is equivalent to writing unit tests after shipping to production: the tests are shaped by the known behavior of the code, which means they test what the code does rather than what it should do.

The journals that have adopted registered reports have discovered that the main effect is not the elimination of p-hacking — though that matters. The main effect is that specifying the test before running it forces the researcher to articulate exactly what would count as a valid result. That articulation is where the scientific reasoning is. The rest is execution.

What this changes

The tools required to implement a specification cascade for peer review already exist. Preprint servers provide commit infrastructure. Open review platforms provide structured visible process. Structured review criteria with explicit operational definitions are a design choice, not a technical constraint. Reviewer quality tracking is a data engineering problem, not a conceptual one. Registered reports demonstrate that pre-results design review is operationally viable.

What is missing is the specification cascade that connects them — the formal structure that makes each stage’s outputs the verified inputs to the next stage, and that creates a feedback loop from outcomes back to the calibration of evaluators.

This is the same gap that Organizational Schema Theory identifies in business operations: not a shortage of processes, but a shortage of specification. Organizations have procedures, policies, and guidelines in abundance. What they lack is the hierarchical specification structure that makes those elements traceable to each other and to the outcomes they are meant to produce. When a business implements OST’s cascade correctly, the connection from purpose to sourcing becomes auditable. When a reviewer makes a recommendation, it should be traceable to the criteria they applied, the calibration history that validates those criteria, and the purpose statement that justifies them.

Science already runs this process. It has simply never written down the specification.

The metamerism problem in brand measurement — where structurally different brands collapse to identical scores under dimensional compression — has a direct analogue in peer review, explored in the companion article on spectral metamerism. Two papers can receive identical peer review outcomes despite being structurally different in quality, because the evaluation instrument collapses multidimensional quality to a binary accept/reject decision. The null space of that projection is where peer review’s systematic failures live. Specifying the dimensions before collapsing them does not eliminate the null space. It makes the null space visible, and visible problems can be engineered around.

The specification must precede the implementation. Science learned this when it developed the scientific method. It is still learning it for the process that produces science itself.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint

Open-source toolkit: GitHub

The Diagnosis Everyone Gets Wrong

Brian Chesky says your company has too many meetings because it has too many people. A-players hire A-players; B-players hire lots of C-players. The C-players scatter, pulling in different directions, and suddenly you have meetings about meetings.

He is right about the symptom. But the root cause is one layer deeper.

Meetings exist to compensate for missing specification.

When a process has no testable contract — no clear input, output, quality gate, or ownership boundary — people fill the gap with synchronous alignment. They meet to agree on things that should have been specified before anyone was hired.

Why Meetings Feel Productive

Here is the part nobody talks about: meetings feel good.

They satisfy real social needs. Belonging. Status. Being heard. The experience of sitting in a room and reaching consensus activates the same reward circuits as collaboration, problem-solving, and team bonding. People leave meetings feeling like they accomplished something.

They often did — socially. But from the process perspective, what happened was realignment. The system drifted from its intended state, and a group of humans spent 45 minutes manually correcting the drift. Then the system will drift again, and they will meet again.

For the humans, it is a social event. For the process, it is muda — waste. Not because coordination is bad. Because re-deriving what should already be written down is pure overhead.

This is why “meeting-free Wednesdays” never work. You are treating the social surface while leaving the structural cause intact. The meetings come back on Thursday because the specification gap did not close on Wednesday.

The Lean Manufacturing Parallel

Toyota’s production system solved this decades ago. Every handoff between stations is specified as a testable contract: what arrives, in what condition, at what time, with what quality gate. If the contract is met, no coordination is needed. If it breaks, the andon cord pulls — not a meeting, but an immediate, visible signal.

The result: Toyota runs some of the most complex manufacturing operations in the world with remarkably few coordination meetings. The specification carries the alignment. The process does not drift because the contract prevents drift.

In software, the same principle produces continuous integration. A test suite replaces the status meeting. The build either passes or it does not. Nobody schedules a meeting to discuss whether the code works. The specification answers the question automatically.

Why Expert Leaders Are Walking Specifications

Chesky’s fix — functional structure, expert leaders who manage through the work — works precisely because it reduces the specification gap. An expert leader who reviews every design artifact is a living specification. They carry the quality standard in their head. Decisions are fast because the standard is present in the room.

Jony Ive did not need meetings about design quality because he was the design specification. His judgment, applied directly to the work, replaced the meetings that would otherwise be needed to align a team on “what good looks like.”

The problem: this does not scale beyond the expert’s working memory. When the organization grows past the point where one person can review everything, the implicit specification breaks down. And the meetings return.

What Scales Is Explicit Specification

What Toyota, continuous integration, and Ive’s design studio share is not a management style. It is a structural property: the specification is explicit enough that alignment happens through the work itself, not through meetings about the work.

For a manufacturing line, the specification is a process contract. For a software team, it is a test suite. For a design studio, it was Jony Ive’s direct judgment.

The question for every organization is: what carries your specification?

If the answer is “meetings,” then your specification is implicit. It lives in people’s heads, and every meeting is an attempt to re-synchronize those heads. The overhead scales quadratically with team size — which is exactly why meeting load explodes as companies grow.

If the answer is “documents, contracts, tests, or validated artifacts,” then your specification is explicit. Alignment scales linearly. Meetings become optional — reserved for genuinely novel problems where no specification yet exists.

The Test

Look at your calendar for next week. For every recurring meeting, ask:

1. What decision or alignment does this meeting produce?

2. Could that decision be derived from a written specification instead?

3. If the specification existed, would this meeting still be necessary?

If the answer to #3 is “no” for more than half your meetings, you do not have a meeting problem. You have a specification problem.

Every recurring meeting in your company is a specification that was never written. The meeting is the symptom. The missing spec is the disease.

This article applies Organizational Schema Theory (OST) to the meeting problem. OST models organizations as version-controlled specifications — when the spec is explicit, alignment is structural, not social. More at orgschema.substack.com.

20 research papers on Zenodo. Open-source toolkit on GitHub.

Our food safety plan runs on every git push. It passed 47 times this month. How many times did yours run?

If the answer is “once, during the annual audit,” you have a compliance department. If the answer is “every time anything changes,” you have compliance as a feature. The difference is not philosophical. It is architectural.

The compliance department model

In most businesses, compliance is a separate function. There is a compliance team (or a compliance person, or a compliance consultant who visits quarterly). Their job is to ensure that the business meets regulatory requirements: food safety, workplace safety, accessibility, data protection, environmental standards, industry certifications.

The compliance workflow looks like this:

1. Regulators publish requirements.

2. The compliance team interprets the requirements and creates internal policies.

3. The policies are documented (usually in a binder, a SharePoint folder, or a compliance management platform).

4. Operations is told to follow the policies.

5. The compliance team audits operations periodically to check compliance.

6. Non-conformances are documented, corrective actions are assigned.

7. Repeat.

This model has structural problems:

Separation. Compliance lives in a different department, reports to a different manager, operates on a different cadence. Compliance requirements and operational specifications exist in different documents, different systems, different mental models. When operations changes, compliance may not know. When regulations change, operations may not adapt.

Periodicity. Compliance is verified periodically — annually, quarterly, monthly at best. Between audits, the business operates unverified. A process changes in March. The audit happens in September. For six months, the business may be non-compliant without knowing it.

Reactivity. Compliance detects non-conformances after they occur. The audit finds that the cleaning schedule was not followed, that the temperature log was not completed, that the allergen declaration is out of date. Corrective actions address past failures. They do not prevent future ones.

Cost. Separate compliance is expensive. The compliance team, the compliance software, the audit process, the corrective action workflow — all dedicated infrastructure for a function that should be a property of normal operations.

Compliance as CI/CD: HACCP critical control points as automated test assertions with real-time pass/fail status.

The compliance-as-feature model

In software engineering, security shifted from a department to a feature. The old model: a security team audits the code after development. The new model: security tests run as part of the CI/CD pipeline. Every code change is automatically checked against security requirements before deployment. This is “DevSecOps” — security integrated into the development workflow, not bolted on after.

Orgschema applies the same pattern to operational compliance. Compliance requirements are not separate documents. They are tests in the same pipeline that validates everything else.

Here is how it works in practice:

Compliance rules as L0 constraint contracts

In orgschema’s TDD cascade, Level 0 contains three types of contracts:

• Experience contracts: What customers should perceive. “Espresso should taste rich and balanced.”

• Constraint contracts: What regulation mandates. “All 14 EU allergens must be declared per Regulation 1169/2011.”

• Commitment contracts: What the business voluntarily promises. “All coffee is direct-trade sourced.”

Constraint contracts sit alongside experience contracts as first-class acceptance tests. They are not separate documents in a compliance binder. They are entries in the same specification file, validated by the same pipeline.

constraint_contracts:
  food_safety:
    regulation: “EU Regulation 852/2004”
    requires:
      - haccp_plan_documented
      - critical_control_points_monitored
      - corrective_actions_defined
      - temperature_logs_maintained
    validation: “CI/CD + quarterly external audit”
​
  allergen_declaration:
    regulation: “EU Regulation 1169/2011 Annex II”
    requires:
      - all_14_allergens_assessed_per_product
      - cross_contamination_risks_documented
      - customer_communication_procedure_defined
    validation: “CI/CD on every product change”
​
  workplace_safety:
    regulation: “EU Directive 89/391/EEC”
    requires:
      - risk_assessment_per_workstation
      - ppe_requirements_documented
      - incident_reporting_procedure_defined
    validation: “CI/CD + annual external review”

Compliance validation in CI/CD

When anyone changes a product specification — adds an ingredient, modifies a recipe, switches a supplier — the CI/CD pipeline validates compliance automatically:

Commit: “Add hazelnut syrup option to latte menu”
​
CI/CD pipeline runs:
  Schema validation: PASS
  Cross-reference: PASS
  Contract satisfaction: PASS
  Allergen check: FAIL
    - hazelnut_syrup contains tree_nuts (EU allergen #8)
    - products/latte.yaml allergen declaration does not include tree_nuts
    - constraint_contract allergen_declaration requires all 14 allergens assessed
​
  BLOCKED: Update allergen declaration before this change can proceed.

The non-compliant change is caught before it reaches the menu. Not during the next audit. Not when a customer has a reaction. Before the change takes effect.

This is compliance as a feature. The compliance check is not a separate audit performed by a separate team. It is an automated test that runs as part of the normal operational workflow. The person adding the hazelnut syrup does not need to remember to check allergens. The pipeline remembers.

HACCP as testable assertions

HACCP (Hazard Analysis and Critical Control Points) is the standard food safety methodology. A HACCP plan identifies critical control points — process steps where safety hazards can be prevented, eliminated, or reduced to acceptable levels — and defines monitoring procedures, critical limits, and corrective actions.

In a traditional HACCP plan, these are paragraphs in a document:

“CCP-1: Milk storage temperature. Critical limit: below 5 degrees Celsius. Monitoring: check temperature log twice daily. Corrective action: discard milk if temperature exceeds 8 degrees Celsius for more than 2 hours. Responsible: shift manager.”

In orgschema, this is a testable assertion:

critical_control_points:
  ccp_1_milk_storage:
    hazard: “pathogen growth in dairy”
    critical_limit:
      parameter: temperature_celsius
      max: 5.0
    monitoring:
      frequency: “twice_daily”
      method: “temperature_log_reading”
      responsible: “shift_manager”
    corrective_action:
      trigger: “temperature > 8.0 for > 2 hours”
      action: “discard_affected_milk”
      documentation: “incident_report_required”
    satisfies_constraint: “food_safety.haccp_plan_documented”

The schema validator checks that every CCP has a critical limit, a monitoring frequency, and a corrective action. The cross-reference checker confirms that the CCP references a valid constraint contract. The pipeline catches missing CCPs, incomplete monitoring definitions, and broken traceability chains.

When the health inspector arrives, you do not hand them a binder. You show them the git log: “Here are our HACCP specifications. Here is the CI/CD pipeline that validates them on every change. Here is the commit history showing every modification, who made it, and whether it passed validation. Here are the 47 successful pipeline runs this month.”

What changes when compliance is a feature

Speed of regulatory response

A new regulation takes effect. In the compliance-department model: the compliance team reads the regulation, interprets it, drafts a policy, circulates it for review, updates the compliance documentation, trains operations, and audits for compliance. Timeline: months.

In the compliance-as-feature model: add the constraint contract to L0, run the pipeline, see which operational specifications satisfy it and which do not. The gaps are visible immediately. The fixes are specific. The validation is automatic. Timeline: days.

Compliance confidence

The compliance-department model provides point-in-time confidence: “We were compliant on the audit date.” Between audits, confidence degrades because changes occur without compliance verification.

The compliance-as-feature model provides continuous confidence: “Every change since the last audit has been validated against compliance requirements.” The confidence does not degrade between audits because the pipeline runs continuously.

Audit efficiency

Auditors spend most of their time verifying that documented procedures match actual practice. With orgschema, the specification IS the actual practice (validated by CI/CD), and the audit trail IS the git history. The auditor’s job shifts from “verify that documentation matches reality” to “verify that the validation pipeline is correctly configured.”

This is a meaningful reduction in audit scope. The auditor checks the test suite and the test results, not every individual procedure.

Cost reduction

When compliance is embedded in the operational pipeline, the marginal cost of compliance for each new change approaches zero. The pipeline runs automatically. No separate compliance review. No separate compliance documentation update. No separate compliance audit of the specific change.

The fixed cost of setting up the compliance-as-feature model (writing constraint contracts, configuring the pipeline) is real. But it is a one-time investment that amortizes over every subsequent change. The compliance-department model has a marginal cost for every change — because every change needs separate compliance review.

The broader pattern

Compliance-as-feature is not limited to food safety. The pattern applies to any regulatory domain:

Data protection (GDPR). Constraint contracts specify data handling requirements. The pipeline validates that product and process specifications comply with data retention, consent, and access requirements.

Accessibility (WCAG/ADA). Constraint contracts specify accessibility requirements. The pipeline validates that customer-facing specifications meet accessibility standards.

Environmental (ESPR/DPP). Constraint contracts specify digital product passport requirements. The pipeline validates that product specifications contain all required environmental data.

Financial (SOX/PCI). Constraint contracts specify financial controls and data security requirements. The pipeline validates that process specifications implement required controls.

In each case, the pattern is the same: regulatory requirements become L0 constraint contracts, operational specifications satisfy those contracts, and the CI/CD pipeline validates satisfaction continuously.

What to do

If you are currently running compliance as a department:

1. Pick one regulation. Start with the one that causes the most operational friction — probably food safety or allergen management.

2. Write the constraint contracts. Express the regulation’s requirements as testable assertions. Not “comply with EU Regulation 1169/2011” — instead: “all 14 allergens in Annex II must be assessed for every product, with cross-contamination risks documented.”

3. Link to existing specifications. If you have orgschema product specifications, add satisfies_constraint annotations. If you do not, start specifying products with constraint satisfaction in mind.

4. Add to the pipeline. Extend your CI/CD pipeline (or create one) to validate constraint satisfaction. The allergen check is a good first test: does every product specification include an allergen declaration that covers all 14 EU allergens?

5. Show the auditor. On the next audit, demonstrate the continuous validation model. Auditors are increasingly familiar with automated compliance (from software auditing). Showing a CI/CD pipeline that validates food safety on every change is not exotic — it is best practice arriving in a new domain.

Compliance is not a department that checks your work after the fact. It is a property of a well-specified system — a feature that runs automatically, validates continuously, and catches non-conformances before they reach the customer.

Build it into the pipeline. Let the tests run. And retire the binder.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

The first location worked. The coffee was good, the regulars came back, the numbers made sense. So you open a second one.

Six months later, the second location is not the first. The espresso tastes different. The service is slower. The vibe is off. Customers who visited because someone told them about the first location leave disappointed. The online reviews mention inconsistency.

This is the second location problem. And it is not about the coffee.

What actually breaks

When a business opens a second location, the obvious things get copied: the menu, the logo, the equipment list, the paint colors. The non-obvious things do not: the barista’s intuition about grind adjustment when humidity changes, the opening manager’s particular way of arranging the pastry case, the implicit understanding of when to bus tables during a rush, the sound choices that make the afternoon feel right.

The first location runs on tacit knowledge — operational intelligence that lives in people’s heads, in habits, in muscle memory. It was never written down because it did not need to be. One location, one team, one set of shared assumptions.

The second location has none of this. It has a new team that received a training manual (if you wrote one), a list of recipes (if you standardized them), and a general sense of “make it like the other place.” The gap between what was transferred and what was needed becomes visible in the first week and widens every month.

Multi-unit operators know this pattern. The industry term is “replication fidelity” and the data is sobering: roughly 60% of multi-unit restaurant expansions underperform first-location benchmarks in their first year. The standard response is more training, more oversight, more mystery shoppers. These help. They do not solve the structural problem: you cannot replicate what you have not specified.

Traditional franchise replication versus orgschema fork: time, cost, and drift detection comparison.

The tacit knowledge trap

The reason most expansions fail is not incompetence. It is that the knowledge required to run the business was never made explicit.

Consider everything that goes into making a consistent espresso across two locations:

• The grind setting (which changes daily based on bean age, humidity, and equipment wear)

• The dose weight (which has an acceptable range, not a single number)

• The extraction time window (which implies acceptable variation)

• The milk temperature target (which differs for different drinks)

• The cup selection (which affects perceived temperature and flavor)

• The presentation standard (which nobody wrote down but everyone at Location A agrees on)

At Location A, the head barista calibrates the grinder every morning, adjusts based on how the first shots pull, and communicates the setting to the team. This happens through conversation, through pulling a shot together, through years of shared context. At Location B, the new head barista calibrates based on whatever they learned during their two weeks of training at Location A. The settings drift. The coffee drifts. The experience drifts.

This is not a coffee problem. It is a knowledge management problem. And it applies to every business that depends on operational consistency across multiple instances: restaurants, retail stores, clinics, service centers, fitness studios.

What orgschema makes explicit

Orgschema forces the tacit into the explicit. Not by writing a longer manual, but by specifying testable contracts at each level of the operation.

The Spectra Coffee demo includes a Friedrichshain location variant that demonstrates this. Both locations — the original and the Friedrichshain fork — share identical specifications at Levels 0 through 2:

• L0 (Customer Experience Contract): Same perception targets across all eight SBT dimensions. The espresso should be perceived identically by customers at both locations.

• L1 (Signal Requirements): Same signals must be emitted. Visible craft preparation, aroma at entrance, staff knowledge about origin.

• L2 (Process Contracts): Same quality gates. Extraction 25-30 seconds, temperature 92-94 degrees Celsius, dose 17-19 grams.

The differences appear at Levels 3 through 5:

• L3 (Procedures): Friedrichshain has a different opening sequence (different building, different alarm system).

• L4 (Inputs): Different water mineral profile (different municipal supply, different filtration adjustment).

• L5 (Sourcing): Different bread supplier for pastries (local baker vs. central kitchen).

The difference between the two locations is exactly 6 parameter overrides in a YAML file. They pass the same 47 quality gate tests.

# locations/friedrichshain/overrides.yaml
location:
  name: “Spectra Coffee - Friedrichshain”
  address: “Boxhagener Str. 42, 10245 Berlin”
​
overrides:
  water:
    tds_source: 280  # higher than Kreuzberg municipal
    filtration: “additional_softening_stage”
  pastry_supplier:
    name: “Backhaus Sievert”
    delivery_schedule: “daily, 06:00”
  opening_procedure:
    alarm_code_location: “keypad_inside_rear_entrance”
    key_handoff: “owner_at_location_daily”
  seating:
    capacity: 28  # smaller than flagship
    outdoor: false  # no terrace

This is not a longer training manual. It is a specification that makes the differences between locations visible, bounded, and testable. A new manager at Friedrichshain does not need to figure out “how to make it like the other place.” They need to implement the same L2 contracts with 6 specific parameter adjustments.

Git diff as expansion intelligence

The power of version-controlled specifications becomes clear at expansion time. git diff between Location A and Location B is not a list of everything that is different. It is a test-aware diff: it shows which layers changed and whether the contracts (tests) are still satisfied.

When Location B’s barista adjusts the grind setting, that change is captured at L3 (procedure). The L2 contract (extraction time 25-30 seconds) is the test. If the grind change produces extraction times within range, the test passes. If it does not, the pipeline flags it.

This means expansion intelligence is structural, not anecdotal. Instead of “the Friedrichshain location is struggling,” you get: “the Friedrichshain location is failing the L2 extraction time contract — extraction averaging 33 seconds, 3 seconds above threshold. L3 procedure check: grinder calibration frequency is weekly instead of daily.”

The diagnosis is specific. The fix is specific. The validation is automatic.

The franchise parallel

Traditional franchising solves the second location problem through prescription: a 500-page operations manual that specifies everything from fryer temperature to greeting scripts. The franchisee pays $500,000 or more for the right to follow the manual, plus ongoing royalties of 4-8% of revenue.

Orgschema solves it through testing. Instead of prescribing how to do everything, it specifies what must be achieved. The contracts (L0-L2) are the franchise agreement. The procedures (L3-L5) are the franchisee’s implementation.

The franchise model worked when tacit knowledge could only be transferred through human training and oversight. Orgschema works because tacit knowledge has been made explicit, testable, and portable.

The metadata layer: what actually needs to be consistent

The second location problem is usually framed as a consistency problem. It is more precisely a metadata consistency problem.

The process — making coffee — is already specified in the test suite. The extraction contract says 25-30 seconds. The temperature contract says 92-94 degrees Celsius. These are portable by definition. Any location, any equipment, any barista can be trained to pass these tests. The process specification travels.

What does not travel automatically is the organizational metadata: who coordinates decisions, how knowledge flows between staff, what tacit assumptions guide moment-to-moment choices, which escalation path exists when something breaks. At Location A, this metadata was grown organically. It emerged through months of daily practice, through the particular friction between this manager and that barista, through the specific failures that taught the team how to recover. Nobody wrote it down because nobody needed to — it lived in the relationships and routines of a single coherent team.

The second location needs that organizational metadata explicitly specified. It cannot evolve organically in time, because organic evolution takes months and the lease clock runs from day one. The new team arrives with process training but without the accumulated coordination intelligence of the first location. They know how to pull the shot. They do not know how to run the organization.

This is the gap that kills second locations. Not the coffee. The coordination overhead that was never made explicit because the first location never needed it explicit.

Orgschema addresses this through the same mechanism it uses for process consistency: explicit specification at each level. The process layer (L0-L2 contracts) makes value output portable. The organizational metadata layer (L3-L5) documents the coordination logic — the opening sequences, the escalation procedures, the supplier communication rhythms, the exception-handling protocols — so that it can be instantiated in a new team without depending on tacit transfer.

The insight from the Friedrichshain example is precise. Six parameter overrides separate the two locations. Those six overrides are not process changes — they are organizational metadata changes. Different water filtration setup. Different pastry supplier and delivery schedule. Different building access procedure. Different seating configuration. The process contracts are identical. The organizational configuration differs exactly where local conditions require it.

The second location is an org metamer of the first: different people, different suppliers, different physical procedures, different building. But the same process contracts and the same value output. Metamerism means same output, different composition. Organizational metamerism means same customer experience, different organizational form.

The practical implication is a different question to ask before expansion. Not “how do we copy the first location” but “what organizational metadata did the first location accumulate that we have never written down.” The test suite already captures the process. The expansion task is to capture the coordination logic — to make the organizational metadata explicit enough that a new team can instantiate it without the years of organic evolution the first team had.

Specify the process. Document the coordination metadata. Let the new location be a metamer, not a copy.

What multi-unit operators should do

If you are considering a second location (or a third, or a tenth), orgschema provides a methodology:

Before expansion:

1. Specify your current operation. Write the contracts (L2) that define your quality. Not “make good coffee” — the measurable, testable version. Extraction time, temperature, dose, yield, freshness window. Do this for every product and every customer-facing process.

2. Identify what is tacit. The contracts will reveal gaps: things you know are important but have never measured. The head barista’s grind adjustment protocol. The manager’s table-turn timing. The cleaning rhythm that keeps the space feeling right. Specify these.

3. Separate contracts from procedures. Your contracts (what must be achieved) should be location-independent. Your procedures (how to achieve it) will vary. The grind setting is a procedure. The extraction time is a contract. Do not confuse them.

During expansion:

4. Fork, do not copy. Create the new location as a fork of the specification. It inherits all L0-L2 contracts. Override only what must change: local suppliers (L5), specific equipment (L4), location-specific procedures (L3).

5. Run the test suite from day one. The CI/CD pipeline should validate the new location’s specifications before it opens. If a contract cannot be met with the available equipment or suppliers, the pipeline tells you before you sign the lease.

After expansion:

6. Use drift as signal. When the new location’s procedures diverge from the original, that is not automatically a problem. It is information. If the contracts still pass, the divergence is valid local adaptation. If the contracts fail, the divergence needs attention. The test suite makes this distinction automatically.

The second location problem is a specification problem. You cannot replicate what you have not specified. You cannot verify what you have not tested. Orgschema gives you both: the specification and the test suite.

The difference between Location A and Location B should be a git diff, not a mystery.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

In March 2026, Terence Tao described what he called the “deductive overhang” — the accumulation of verifiable consequences faster than the scientific community can verify them. AI, he observed, was making research “richer and broader” but not deeper. What was needed, he said, was “a semi-formal language for the way that scientists actually talk to each other.”

Tao’s immediate context was mathematical proof, where verification is decidable — a proof either satisfies the axioms or it does not. But the asymmetry he identified applies with greater force to empirical science, where verification depends on experimental design, statistical inference, and replication. And it is getting worse. Large language models can now generate a hundred plausible research hypotheses in an afternoon, complete with literature grounding and proposed methodologies. The generation side of science is accelerating. The verification side is not.

This is not new. Peer-reviewed publications grew 5% per year between 2016 and 2022, while reviewer availability grew at less than half that rate. The replication crisis — documented across psychology, medicine, and economics — had already demonstrated that the scientific ecosystem produces claims faster than it can verify them. LLMs threaten to widen this gap by orders of magnitude.

The standard response has been methodological: pre-registration, registered reports, stricter statistical thresholds, open data mandates. These interventions address the quality of individual studies. They do not address the scalability of verification itself. A registered report is still a PDF. Its hypotheses, acceptance criteria, and methodology are still expressed in natural language, legible to human readers but opaque to machines.

The problem is not that we lack rigor. The problem is that we lack structure.

The Pattern

This has happened before. Twice, at civilizational scale.

The printing press (1450s) reduced the cost of producing written documents by roughly two orders of magnitude. The immediate consequence was an explosion of pamphlets and treatises of every kind — alchemical recipes next to astronomical observations, political propaganda next to anatomical descriptions. The generation breakthrough was mechanical. The verification problem was epistemic: how do you distinguish a reliable claim from an unreliable one when both arrive in the same printed format?

The specification solution took two centuries to consolidate: the scientific method. Bacon’s Novum Organum (1620), the Royal Society (1660), Newton’s Principia (1687). Collectively, they established a specification for credible knowledge claims — falsifiable predictions, controlled experiments, mathematical formalization, independent replication. The scientific method did not reduce the volume of printed material. It provided a structural standard against which claims could be evaluated.

The internet (1990s) reduced the cost of publishing information by another two orders of magnitude. Early web pages were unstructured text with hyperlinks — human-readable but machine-opaque. The generation breakthrough was connectivity. The verification problem was discovery: how do you find reliable information when every page looks the same?

The specification solutions arrived over the following decade: HTML metadata, PageRank, schema.org, knowledge graphs. These standards did not reduce the volume of web content. They made it machine-parseable, enabling automated discovery, ranking, and verification.

The pattern is identical each time: a generation breakthrough creates a volume problem that cannot be solved by scaling the old verification method. Human curation cannot keep up with the printing press. Human librarians cannot keep up with the web. The solution in each case was not faster humans but a specification standard that made the new volume tractable to automated processing.

Large language models (2020s) reduce the cost of generating plausible scientific text by yet another order of magnitude. The generation breakthrough is cognitive. The verification problem is epistemic, just as it was in the fifteenth century. And the verification infrastructure remains pre-digital. A scientific paper in 2026 is structurally identical to a scientific paper in 1996: a PDF containing natural language, evaluated by two to three human reviewers over a period of weeks to months.

The historical pattern predicts a specification response. Not faster reviewers. A structural standard for scientific claims.

The Last Unstructured Artifact

Consider what we already structure.

Websites have HTML metadata, Open Graph tags, structured data markup. Financial reports have XBRL. Legal contracts have emerging machine-readable formats. Medical records have FHIR. Software has package manifests, dependency files, and API specifications. Even recipes have schema.org/Recipe.

Scientific papers have none of this. The claims are buried in prose. The acceptance criteria are implicit or absent. The dependency on prior work is expressed through citation — which indicates that a paper was read but not which specific claim is load-bearing. The conditions under which the claims would be falsified are rarely stated explicitly, and when they are, they are not machine-extractable.

When a foundational paper is retracted, identifying every downstream claim that depends on it requires a human to read every citing paper and judge the nature of the citation. For a paper with fifty citations, this is tedious. For a paper with five thousand, it is impossible. And recent research confirms the urgency: the majority of post-retraction citations are positive, suggesting that authors either do not know or do not check whether their cited sources have been retracted.

Scientific papers are where websites were in 1995. Human-readable. Machine-opaque. Multiplying faster than any manual process can curate them.

What paper.yaml Looks Like

Paper Spec is a YAML-based standard that provides a machine-readable companion file for any scientific paper. A paper.yaml sits alongside a paper — in a repository, as supplementary material, or in a registry — and answers seven questions that every reader eventually asks:

1. What does this paper claim?

2. How were those claims tested?

3. What would prove them wrong?

4. Can I reproduce this?

5. What does this depend on?

6. What are its known limits?

7. Where can I find it?

Here is what that looks like for a real paper — Kahneman and Tversky’s (1979) prospect theory:

spec_version: “0.1.0”
​
meta:
  title: “Prospect Theory: An Analysis of Decision under Risk”
  authors:
    - name: “Kahneman, Daniel”
      affiliation: “Hebrew University of Jerusalem”
    - name: “Tversky, Amos”
      affiliation: “Stanford University”
  doi: “10.2307/1914185”
  date: “1979-03-01”
  venue: “Econometrica”
​
claims:
  - id: “H1”
    type: hypothesis
    statement: >
      People underweight outcomes that are merely probable
      compared to outcomes obtained with certainty (the
      certainty effect), leading to risk aversion in choices
      involving sure gains and risk seeking in choices
      involving sure losses.
    testable: true
    tested_in_paper: true
    status: supported
​
  - id: “H2”
    type: hypothesis
    statement: >
      The value function is defined on deviations from a
      reference point, is generally concave for gains and
      convex for losses, and is steeper for losses than
      for gains (loss aversion).
    testable: true
    tested_in_paper: true
    status: supported
    depends_on: [”H1”]
​
acceptance:
  - claim_id: “H1”
    criterion: >
      In forced-choice experiments, a statistically significant
      majority of subjects prefer a certain gain over a
      probabilistically equivalent or superior gamble, and
      prefer a gamble over a certain loss of equivalent
      expected value.
    falsification: >
      Subjects show no systematic preference for certainty
      in gains or gambling in losses — choices are consistent
      with expected utility theory.
​
dependencies:
  - reference: >
      von Neumann, J., & Morgenstern, O. (1947).
      Theory of Games and Economic Behavior.
    claim: >
      Expected utility theory — the baseline model
      that prospect theory replaces.
    relationship: contradicts
    critical: true
​
limitations:
  - description: >
      All experiments used hypothetical choices with
      university students. No real monetary stakes.
      Generalizability to real economic decisions and
      non-student populations is assumed but not tested.
    severity: major
    addressable: true

Read that again. In under forty lines, you know what the paper claims, what would prove it wrong, what it critically depends on, and what its authors acknowledged they did not test. A human can write this in thirty minutes. Any YAML parser on Earth can consume it.

Every section except meta is optional. A paper.yaml with nothing but metadata is still a structured bibliographic record. Each additional section adds value independently. There is no minimum threshold for utility.

What This Enables

The real power appears when many papers have specification files. Four capabilities become possible that are currently impossible or prohibitively expensive:

Retraction cascade analysis. When Paper A is retracted, a machine can traverse the dependency graph and identify every downstream paper whose claims critically depend on Paper A. No human reading required. The critical: true flag distinguishes load-bearing citations from ceremonial ones — a distinction that citation counts cannot make.

Contradiction detection. When Paper A and Paper B both depend on Paper C but draw opposite conclusions, the contradictions section — supplemented by automated comparison of results entries — can flag the conflict. Currently, contradictions in the literature are discovered by individual readers who happen to have read both papers.

Claim-level search. Instead of searching for papers by keyword, a researcher can search for specific claims: “Find all papers that claim working memory mediates the effect of sleep deprivation on decision quality.” This is not possible with unstructured papers. It is trivial with a corpus of paper.yaml files.

Automated pre-review. An LLM can read a paper and its paper.yaml in parallel and flag discrepancies: “Section 4 introduces Proposition 3, which is not listed in the claims section.” Not a replacement for peer review, but a first-pass filter that catches structural problems before a human reviewer sees the paper.

These are not speculative applications. They follow directly from having machine-readable claims, dependencies, and acceptance criteria. The same way that structured web data enabled search engines, structured paper data enables verification infrastructure.

What This Does Not Do

Paper Spec does not judge quality. It does not decide whether a claim is good, whether a methodology is sound, or whether a p-value is meaningful. It records what the authors state. The spec describes structure, not merit.

It does not replace peer review. Peer review is a judgment about whether the claims are worth believing. Paper Spec is a representation of what those claims are. These are complementary, not competing. A reviewer who receives a paper with a paper.yaml can start from a structural summary rather than excavating the same information from thirty pages of prose.

It does not require anyone to change how they write papers. A paper.yaml is a companion file, not a replacement for the paper itself. You write your paper exactly as you always have. Then you spend thirty minutes writing a YAML file that indexes it.

It does not require universal adoption to be useful. A single paper.yaml has value: it is a structured record of that paper’s claims and dependencies. A hundred have more. A thousand have dramatically more. But the network effect is not required for individual benefit — the same incremental-adoption design that made HTML metadata succeed before the entire web was annotated.

The Landscape

Paper Spec is not the first attempt to bring structure to scientific publishing. It occupies a specific position relative to existing standards:

The distinguishing feature is not any single column. It is the combination: human-writable AND machine-readable AND full-paper scope AND acceptance criteria AND dependency tracking AND incremental adoption. No existing standard covers all six.

The reason is a design constraint that prior projects did not prioritize: the spec must be writable by the author, in a text editor, in thirty minutes, with no specialized tooling. Nanopublications require RDF. Scienceverse requires R. SciKGTeX requires LaTeX. ORKG requires crowd annotators. Each of these is a capable system. None of them asks the question: can a working researcher do this in half an hour with the tools they already have?

YAML is not glamorous. It is not a knowledge graph. It is not an ontology. It is a format that every researcher can read without training and write without tooling. HTML succeeded for the same reason. The best specification standard is not the most expressive one. It is the one people actually use.

Try It

Paper Spec v0.1.0 is published. The specification, JSON Schema, twenty worked examples, a Python template generator, and an LLM prompt are all in the public repository.

Here is how to start:

1. Pick one of your papers — ideally one where you remember the claims clearly.

2. Open a text editor. Start with the meta section: title, authors, DOI, date, venue.

3. Add one claim. Give it an ID, a type, a statement. Mark whether it was tested and whether it was supported.

4. Add one acceptance criterion. What would confirm it? What would falsify it?

5. Add one dependency. What prior work is this claim load-bearing on? Is that dependency critical?

You now have a Level 2 paper.yaml — more structured than 99.9% of published papers. It took you ten minutes. The remaining sections (methodology, results, data, code, limitations, repositories, submission history) each add independent value. Add them when you are ready.

If you want to validate your file against the schema:

pip install jsonschema pyyaml
python -c “
import yaml, jsonschema, json
with open(’paper.yaml’) as f: doc = yaml.safe_load(f)
with open(’schema/paper-spec-v0.1.0.json’) as f: schema = json.load(f)
jsonschema.validate(doc, schema)
print(’Valid.’)
“

If you want an LLM to draft a paper.yaml from your PDF, the repository includes a prompt designed for exactly that purpose.

The Bet

Every generation breakthrough in information production has been resolved by a specification standard. The printing press got the scientific method. The internet got structured data. LLMs have not yet produced their specification response for the domain where the verification problem is most acute: science itself.

The bet behind Paper Spec is simple: if you make the epistemic content of papers machine-readable, the verification infrastructure will follow. Not because anyone mandates it, but because the tools that become possible — retraction cascades, contradiction detection, claim-level search, automated pre-review — are too useful to ignore once the structured data exists.

The alternative is to continue as we are: generating hypotheses at machine speed, verifying them at human speed, and trusting that an overloaded system of two-to-three reviewers per paper will scale to meet a volume that is about to increase by an order of magnitude.

It will not.

Dmitry Zharnikov is an independent researcher working on structured approaches to scientific knowledge. The academic treatment of the ideas in this article is in “Paper as Specification: A Machine-Readable Standard for Scientific Claims” (Zharnikov, 2026), available on Zenodo. The specification, validator, and twenty worked examples are at github.com/spectralbranding/paper-spec. Paper Spec is open source (CC-BY-4.0 for the specification, MIT for the code).

Our newest barista’s first training task was not pulling a shot. It was reading the test suite — 17 files that define what every process must achieve, and why. Not how to hold the portafilter. Why the extraction window is 25-30 seconds. Not which cleaning products to use. Why the cleaning schedule exists and what customer experience goal it serves.

This is what training looks like when operational knowledge lives in a specification, not in the head of the senior barista.

The oral tradition problem

Coffee has always been an oral tradition. The master teaches the apprentice. The apprentice watches, imitates, practices, and eventually develops the feel. Grind adjustment is tactile. Milk steaming is auditory. Extraction timing is intuitive. The knowledge transfers through proximity, repetition, and years of shared experience.

This works when you have one shop and your best barista never leaves. It breaks the moment reality departs from that ideal — which is immediately and always.

The senior barista takes a sick day. The new hire trained under them does not know why the grind was adjusted yesterday, only that it was. A customer asks about the coffee’s origin and processing method. The barista shrugs — they were taught how to make the drink, not the story behind it. The health inspector asks about the allergen management procedure. The shift manager recites what they remember from training six months ago, which may or may not match current practice.

Oral tradition is high-bandwidth but low-durability. It transfers nuance beautifully and persists terribly. When the senior barista quits, the knowledge walks out the door. When the training was incomplete, the gaps are invisible until they surface as inconsistency, as customer complaints, as failed inspections.

Training from test suite: onboarding flow from git clone through LLM curriculum generation to CI-validated competence. Knowledge persists in the repository, not in any individual’s memory.

What the test suite teaches

An orgschema specification is not a better training manual. It is a different kind of knowledge artifact: a testable specification where every operational parameter traces backward to the customer experience goal it serves.

When the new barista reads the espresso specification, they do not see “set the grinder to 7.” They see:

process_contract:
  extraction:
    time_seconds: [25, 30]
    temperature_celsius: [92, 94]
    dose_g: [17, 19]
    yield_ml: [34, 38]
  satisfies_signal:
    - “experiential.taste_quality”
  satisfies_experience:
    - “experience.product_excellence”

This tells them: the extraction must be 25-30 seconds. The temperature must be 92-94 degrees. The dose must be 17-19 grams. And it tells them why: because this produces the taste quality signal that satisfies the product excellence experience goal.

The “why” changes everything about training. A barista who knows the extraction window is 25-30 seconds will adjust the grind when extraction drifts. A barista who knows why it is 25-30 seconds — because that window produces the taste profile that satisfies the customer experience contract — will understand that a 32-second extraction is not just “wrong by 2 seconds” but “failing the taste quality test.”

The difference is between following a rule and understanding a test. Rule-followers need supervision. Test-understanders self-correct.

The authority shift

In oral tradition, authority derives from seniority. The barista who has been there longest knows the most. Their judgment is trusted because they have accumulated years of tacit knowledge. When they say “the grind needs to be finer today,” the team adjusts.

In a specification-driven operation, authority derives from contribution. The git log shows who changed what, when, and why. The senior barista’s knowledge is not lost in their head — it is committed to the repository. A junior barista who spots an inconsistency between the specification and actual practice can open an issue. A new hire who brings experience from a previous shop can propose a change, and the CI/CD pipeline validates whether the change still satisfies the quality contracts.

This is not a flattening of expertise. The experienced barista still has judgment that the specification cannot capture — when to deviate from the standard dose because the beans are aging, how to adjust for unusual weather, how to read a customer’s mood and adapt the interaction. But the baseline — the minimum standard that every extraction must meet — is explicit, shared, and machine-validated.

The authority to change the specification follows the same pattern as code review: propose a change, explain the rationale, validate against the test suite, merge when approved. The senior barista’s expertise is captured as commits, not as oral pronouncements that may or may not be remembered correctly next week.

What tests cannot capture

Here is the important part: the test suite defines the floor, not the ceiling. The quality gates specify minimum acceptable performance. Everything above the minimum is human premium — irreducible quality that emerges from skill, care, judgment, and personality.

The specification says extraction_time_seconds: [25, 30]. It does not say “produce a shot that makes the customer close their eyes and pause.” The specification says customer_greeting: acknowledgment_within_seconds: 10. It does not say “make the customer feel recognized and welcome.” The specification says latte_art: required: true. It does not say “create a rosetta that makes someone photograph their coffee.”

These are the gaps between L2 (process contract) and L0 (customer experience). The contract specifies measurable quality gates. The experience goal describes a perception that is only partially captured by those gates. The barista who merely meets the contracts produces adequate coffee. The barista who exceeds them — who brings the unmeasurable warmth, the improvisational skill, the genuine care — produces the experience that customers return for.

Orgschema does not replace this human premium. It creates the conditions for it to matter. When the baseline is guaranteed by the specification — every extraction within range, every ingredient traceable, every allergen declared — the barista is freed from being the quality control system and can focus on being the quality amplifier.

In the pre-specification world, the barista’s cognitive load includes: remember the grind setting, remember the dose, remember the cleaning schedule, remember the allergen list, remember the opening procedure, remember the closing checklist. In the specification world, these are validated by the pipeline. The barista’s cognitive load shifts to: read the customer, adjust the interaction, notice the details, exceed the contract.

Training as test comprehension

Traditional barista training follows a curriculum: watch this, practice this, memorize this. The training materials are separate from the operational documents (if operational documents exist at all). The connection between what is taught and why it matters is explained verbally, if at all.

Orgschema training follows the test suite:

Week 1: Read the contracts. Understand what every process must achieve and why. Trace the espresso extraction contract to the taste quality signal to the product excellence experience goal. Understand the chain.

Week 2: Read the procedures. Understand how the contracts are currently implemented. The grinder calibration procedure achieves the extraction time contract. The milk steaming procedure achieves the texture quality contract. The cleaning procedure satisfies both the food safety constraint contract and the environmental cleanliness signal.

Week 3: Practice the procedures. Implement the procedures under supervision. When an extraction falls outside the contract range, diagnose why — not “do it again” but “which parameter drifted and how does it connect to the contract?”

Week 4: Exceed the contracts. Now that the minimum is understood and achievable, develop the human premium. Latte art. Customer interaction. Sensory evaluation beyond the measurable parameters. The test suite is the foundation; everything above it is craft.

This training structure has a property that oral tradition lacks: it is auditable. A manager can verify that a barista understands the traceability chain by asking them to trace any parameter to its experience goal. Not “what is the extraction time?” but “why is the extraction time 25-30 seconds, and what happens to the customer experience if it is 35 seconds?”

The knowledge persistence problem

People leave. In specialty coffee, annual staff turnover averages 60-80%. Every departure takes tacit knowledge with it. Every new hire requires training that recreates knowledge that already existed in the previous person’s head.

Orgschema does not solve turnover. It solves the knowledge loss that turnover causes. When the senior barista leaves, their contributions persist in the repository:

• The grind calibration procedure they refined over months: committed to processes/quality_control.yaml.

• The seasonal blend adjustment they developed: committed to products/espresso.yaml with a seasonal_variation section.

• The opening sequence optimization they figured out: committed to processes/opening_closing.yaml.

The new hire does not start from zero. They start from the accumulated commits of everyone who came before. git log shows the evolution. git blame shows who contributed each parameter. The institutional memory is in the repository, not in the departing employee.

This changes the economics of turnover. In the oral tradition model, losing a senior barista costs months of accumulated knowledge. In the specification model, it costs the unmeasurable human premium — their particular warmth, their specific latte art style, their rapport with regulars — but the operational knowledge persists.

The unmeasurable losses are real and significant. But they are the irreducible core, not the preventable periphery. The preventable loss — documented knowledge walking out the door — is eliminated.

The cultural question

There is a reasonable objection: does specifying the craft kill the craft? If the barista reads YAML instead of learning from a master, do we lose something essential about the human transmission of skill?

The answer depends on what you think training is for. If training is primarily about transmitting technique — hold the portafilter this way, steam the milk to this sound — then specification captures most of it. If training is primarily about transmitting passion, culture, and identity — this is what we care about, this is why we do it this way, this is who we are — then specification captures none of it.

But the best training does both, and orgschema helps with the first so that human teachers can focus on the second. The specification handles the what and the measurable why. The human mentor handles the cultural why and the beyond-specification excellence.

The barista who reads YAML is not a lesser barista. They are a barista with a clearer foundation, a traceable understanding of their craft, and more cognitive space for the parts of the job that no specification can capture.

They read the test suite on day one. By day thirty, they are exceeding it. That is the point.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

Your operations manual was last updated 14 months ago. Twenty-three things have changed since then. You do not know which twenty-three. And you cannot test whether it still works.

This is technical debt. Not in software — in your business.

What technical debt means

Software engineers use “technical debt” to describe the accumulated cost of deferred maintenance. Code that works but is poorly structured, undocumented, or untested. Every shortcut taken during development becomes a liability: harder to modify, easier to break, more expensive to maintain over time.

The defining characteristic of technical debt is not that the code is bad. It is that the code is untestable. You cannot run it through a validation pipeline to check whether it still does what it was designed to do. Changes are risky because the consequences are invisible until something breaks in production.

Your operations manual has the same characteristics. It is a document that describes how your business should work. It was accurate when it was written. Since then:

• A supplier changed their delivery schedule. Someone adjusted the receiving procedure but did not update the manual.

• The health inspector required a new cleaning protocol. The manager implemented it. The manual still describes the old one.

• A staff member discovered a better way to prep cold brew. The team adopted it. The manual does not mention it.

• You changed the espresso blend. The extraction parameters changed. The manual still lists the old parameters.

Each of these is a piece of operational technical debt. The manual and reality have diverged. The gap is invisible — until an auditor checks the manual against practice, or a new employee follows the manual and does something wrong, or an incident occurs and the documented procedure turns out to be obsolete.

Operations manual versus orgschema YAML in git: format, version control, validation, traceability, and drift visibility.

Why traditional manuals fail

Operations manuals fail for the same reason legacy code fails: they cannot be tested.

You cannot run an operations manual through a validation pipeline to check whether it still satisfies the customer experience it was designed for. You cannot diff two versions and see what changed. You cannot trace a procedure back to the business goal it serves. You cannot automatically detect when a change in one part of the manual creates a contradiction in another part.

The result is predictable:

Nobody reads it. The manual is too long, too static, and too disconnected from daily reality. Staff learn from other staff, not from documents. The manual becomes a compliance artifact — something you show the auditor, not something you use to operate.

Nobody updates it. Updating a 200-page PDF requires finding the right section, understanding the formatting conventions, getting management approval, redistributing the updated version, and confirming that everyone discards the old version. The effort is disproportionate to the change. So changes accumulate undocumented.

Nobody trusts it. When the manual is known to be out of date, staff treat it with the same skepticism that developers treat legacy code: “I think this is right, but I’m not sure, so I’ll ask someone who’s been here longer.”

Nobody can verify it. The most dangerous property. When an incident occurs, the first question is: “Did they follow the procedure?” If the procedure in the manual is different from the procedure in practice, the answer is ambiguous. The manual becomes a liability, not a resource.

The orgschema alternative

Orgschema specifications are not a better-formatted operations manual. They are a fundamentally different artifact: version-controlled, schema-validated, cross-referenced, and continuously tested.

Here is the difference:

When someone changes the espresso recipe in an orgschema specification, this is what happens:

Commit: “Adjust espresso dose from 18g to 19g for new blend”
​
git blame shows: Maria Rodriguez, 2024-11-15
git diff shows: products/espresso.yaml, line 14: dose_g: 18 -> 19
​
CI/CD pipeline runs:
  Schema validation: PASS (dose_g is valid integer in range)
  Cross-reference: PASS (references valid process contract)
  Contract satisfaction: PASS (extraction time still 25-30s with new dose)
  Signal coverage: PASS (experiential.taste_quality still satisfied)
  Experience traceability: PASS (L0 product_excellence goal still met)

The change is attributed. The impact is validated. The traceability is maintained. If the dose change caused the extraction time to fall outside the contract range, the pipeline would fail. The non-compliant change would be flagged before it reaches the actual operation.

This is what operations manuals cannot do. Not because they are badly written — because they are the wrong artifact type. A PDF cannot run tests. A YAML specification in a CI/CD pipeline can.

Git blame for operations

git blame is a software engineering tool that shows who last modified each line of code. Applied to orgschema specifications, it provides something operations has never had: complete attribution of operational decisions.

When the health inspector asks “who changed the cleaning protocol and when?”, the answer is not “I think it was last quarter, let me check.” The answer is: “Maria Rodriguez, November 15th, commit 4d610f5. Here is the exact change. Here is the test run that validated it. Here is the chain from the cleaning protocol to the food safety contract to the regulatory constraint.”

When an incident occurs — a customer reports an allergen reaction — the investigation is:

1. git log products/oat_latte.yaml — when was the recipe last changed?

2. git diff HEAD~5 products/oat_latte.yaml — what changed in recent commits?

3. Check CI/CD history — did the allergen validation pass on every commit?

4. Trace the allergen declaration to the supplier specification — is the supplier data current?

This is not forensic guesswork. It is structured investigation using the same tools that software engineers use for production incidents. The operational specification IS the audit trail.

The cost of operational technical debt

Software companies measure technical debt in terms of developer productivity: how much slower are we because of accumulated shortcuts? The same measurement applies to operational technical debt:

Training cost. New employees learn from other employees because the manual is unreliable. This is slower, less consistent, and dependent on who happens to be training them. Orgschema specs are the single source of truth for training — every procedure traces to a contract, every contract explains why.

Incident cost. When something goes wrong, investigating the cause requires interviewing people, checking partial records, and reconstructing what happened. With version-controlled specs, the investigation starts with git log and git diff. The facts are in the commit history.

Compliance cost. Auditors require documented procedures that match actual practice. Maintaining this correspondence manually is expensive. Orgschema maintains it automatically — the specification IS the practice, and the CI/CD pipeline validates the correspondence continuously.

Expansion cost. Opening a second location requires transferring operational knowledge. With a manual, this means weeks of training and months of adjustment. With orgschema, it means git clone and a CI/CD pipeline that validates the new location’s implementation against the shared contracts.

Innovation cost. Changing a procedure is risky when you do not know what depends on it. Orgschema’s traceability chain shows exactly what is affected: change the grind size and the pipeline tells you whether extraction time, taste quality, and customer experience are still satisfied. Change with confidence instead of change with anxiety.

The migration path

You do not need to rewrite your operations from scratch. Orgschema borrows another concept from software engineering: characterization testing.

Characterization tests document what the system currently does, not what it should do. They are the first step in refactoring legacy code: write tests that capture current behavior, then refactor with confidence that you have not broken anything.

Applied to operations:

Step 1: Characterize. Pick one process — espresso preparation. Document what actually happens, not what the manual says should happen. Watch the barista. Measure the extraction time, the dose, the temperature. Write these down as contracts: “extraction_time_seconds: 25-30.”

Step 2: Specify. Put the characterization in YAML. Add the traceability: this extraction time satisfies this taste quality signal, which satisfies this customer experience goal. Now you have one process with full traceability.

Step 3: Validate. Add schema validation. Does the YAML conform to the expected structure? Do the cross-references resolve? Does the contract chain from L0 to L5 have gaps?

Step 4: Expand. Repeat for the next process. And the next. Each process specified reduces the operational technical debt by one unit. The manual shrinks as the specification grows.

Step 5: Retire the manual. When every process is specified, the manual is redundant. The specification is the manual — except it is testable, traceable, version-controlled, and continuously validated.

The operations manual served its purpose. It was the best tool available for capturing operational knowledge in a pre-digital, pre-AI era. But it is the wrong tool for businesses that need to scale, adapt, and prove compliance. It is technical debt.

Pay it down. Specify your operations. Test your specifications. And let the PDF retire.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

In 2019, a group of designers and developers created the Design Tokens Community Group within the W3C. Their goal: standardize the format for sharing design decisions — colors, spacing, typography, shadows — between design tools and code. The result is a JSON specification that replaces the PDF brand book with a machine-readable format that design tools, build systems, and component libraries can consume directly.

This is a quiet revolution. Brand identity is becoming a technical standard.

The PDF problem

A brand identity today lives in a PDF. The brand book specifies: primary color is Pantone 2945C (hex #004B87), body typeface is Inter at 16px, heading typeface is Playfair Display at 32px, minimum logo clearance is 2x the logo height.

The designer reads the PDF and translates these values into Figma. The developer reads the PDF and translates them into CSS variables. The print vendor reads the PDF and translates them into CMYK values. The email marketer reads the PDF and translates them into inline styles.

Every translation is an opportunity for error. The PDF says Pantone 2945C; the developer Googles the hex equivalent and finds three different values on three different websites. The PDF says 16px body text; the email marketer uses 14px because it “looks better” in Outlook. The PDF says minimum clearance 2x; the social media manager eyeballs it.

The brand book is documentation. It describes intent. But it cannot enforce compliance, detect drift, or propagate changes.

Brand.json architecture: W3C Design Tokens (visual identity only) versus full orgschema operational specification.

Design tokens: the first step

Design tokens solve the translation problem for visual identity. Instead of a PDF, brand colors and typography are specified in a structured format:

{
  “color”: {
    “primary”: { “value”: “#004B87”, “type”: “color” },
    “secondary”: { “value”: “#7C878E”, “type”: “color” },
    “accent”: { “value”: “#E87722”, “type”: “color” }
  },
  “typography”: {
    “body”: {
      “fontFamily”: { “value”: “Inter”, “type”: “fontFamily” },
      “fontSize”: { “value”: “16px”, “type”: “fontSize” }
    },
    “heading”: {
      “fontFamily”: { “value”: “Playfair Display”, “type”: “fontFamily” },
      “fontSize”: { “value”: “32px”, “type”: “fontSize” }
    }
  }
}

Figma reads this file directly. The build system generates CSS from it. The email template system references it. One source of truth, zero manual translation.

Design tokens are now supported by Figma, Adobe, Style Dictionary, and dozens of other tools. They solve the visual consistency problem for digital products. But they cover only one dimension of brand identity — the semiotic (visual language). They say nothing about how the coffee should taste, how quickly the customer should be greeted, what the space should smell like, or what values the business should embody.

From brand.json to brand.yaml

Orgschema extends the design token concept from visual identity to the entire business. If design tokens are brand.json for visual identity, orgschema specifications are brand.yaml for the full operational brand.

Design tokens are Level 1 (semiotic signals) in orgschema terms. Orgschema specifies all eight SBT dimensions across all six cascade levels.

The implication: the entire brand — not just the visual system — can be expressed as a machine-readable specification. A single repository contains the color palette AND the espresso recipe AND the customer greeting protocol AND the allergen management policy AND the supplier certification requirements. All traceable to customer experience goals.

Why this matters for platform developers

If brand identity becomes a technical standard, platforms can consume it. Consider the integrations:

Point-of-sale systems. The POS reads products/espresso.yaml and knows the price, ingredients, allergens, modifiers, and margin. No manual menu entry. No discrepancy between the specification and the register.

Training platforms. The LMS reads process specifications and generates training modules with quizzes based on quality gates. “What is the acceptable extraction time range for espresso?” Answer: 25-30 seconds (from processes/quality_control.yaml).

Compliance systems. The food safety platform reads compliance/food_safety.yaml and compliance/allergen_management.yaml and generates the required regulatory documentation. HACCP plans, allergen declarations, cleaning schedules — all derived from the specification.

Interior design tools. The design tool reads brand/identity.yaml and generates material specifications, color schemes, lighting schedules, and spatial layouts consistent with the brand specification.

Customer-facing applications. The mobile app reads the specification and renders allergen information, ingredient provenance, nutritional data, and menu pricing — all from the single source of truth.

This is not theoretical. The Arazzo Specification (2024) defines machine-readable API workflow definitions in YAML/JSON, replacing XML-based BPMN. The EU Digital Product Passport mandate (ESPR, entered force July 2024) requires machine-readable product data for batteries (2026), apparel (2028), and eventually all products. The infrastructure for machine-readable business specifications is being built by regulators and standards bodies. Orgschema provides the business logic layer that these standards need.

The EU Digital Product Passport connection

The European Union’s Digital Product Passport (DPP) requires manufacturers to provide machine-readable product information: materials, origin, recyclability, carbon footprint, compliance certifications. Batteries over 2kWh are first (February 2027), with textiles and apparel following (2028).

An orgschema product specification already contains most of what a DPP requires:

espresso:
  ingredients:
    coffee_beans:
      origin: “Ethiopia, Yirgacheffe”
      processing: “washed”
      certification: “direct_trade”
      carbon_footprint_kg_per_kg: 3.2
    water:
      source: “municipal, filtered”
  allergens:
    declared: [none]
    cross_contamination: [milk, tree_nuts]
  packaging:
    cup: “ceramic, reusable”
    takeaway: “compostable PLA”

A DPP is a product specification. Orgschema specifications are product specifications with additional context — traceability to customer experience goals, quality gates, process requirements. Generating DPP-compliant data from orgschema specs is a format conversion, not a new data collection exercise.

For businesses that already maintain orgschema specifications, DPP compliance is nearly free. For businesses that do not, DPP compliance is a new documentation burden. This is a meaningful competitive advantage as DPP requirements expand across product categories.

Standards bodies and the specification ecosystem

The convergence of several trends creates the infrastructure for brand-as-specification:

W3C Design Tokens (2019-present): Machine-readable visual identity. The semiotic layer.

OSCAL (NIST Open Security Controls Assessment Language): Machine-readable security compliance frameworks. The constraint contract layer.

Arazzo (OpenAPI Initiative, 2024): Machine-readable API workflow definitions. The process interaction layer.

EU DPP/ESPR (2024): Machine-readable product passports. The product specification layer.

MCP (Anthropic Model Context Protocol, 2024): Standardized AI tool interfaces. The LLM interaction layer.

Orgschema sits at the intersection: a framework that connects these emerging standards into a unified business specification with backward traceability to customer experience goals. Each standard covers a slice of the business. Orgschema provides the architecture that connects the slices.

The brand API

If the brand is a specification, and the specification is machine-readable, then the brand has an API.

Not metaphorically. Literally. An orgschema specification exposed through a REST API (or an MCP server) allows any system to query the brand: “What are the brand colors?” “What is the espresso quality specification?” “What allergens are in the oat latte?” “What certifications does our coffee bean supplier hold?”

This is brand.json taken to its logical conclusion. The brand is not a PDF on the marketing team’s SharePoint. It is a queryable, versionable, forkable technical artifact that every system in the organization can reference.

The brand API has consumers:

• The website reads product descriptions and allergen information from the spec

• The POS system reads pricing and modifiers from the spec

• The training platform reads procedures and quality gates from the spec

• The compliance system reads regulatory requirements from the spec

• The LLM reads everything and answers natural language questions about any aspect of the business

One specification. Many consumers. Zero manual translation. Zero drift.

The competitive implication

When brand identity becomes a technical standard, competitive advantage shifts. The brand book was a proprietary document — you paid for it, you owned it, competitors could not access it. But the brand book described intentions, not capabilities.

An orgschema specification describes capabilities: what the business actually does, measured and validated. In the five-level openness taxonomy, a business can publish its schema (what it measures) without publishing its data (specific values). This is the Toyota model: publish the methodology, keep the parameters.

A coffee shop that publishes its orgschema schema says: “Here are the 47 quality parameters we control, across 6 products, 4 process types, and 8 perceptual dimensions.” This tells competitors what excellence looks like — what they should be measuring. But it does not tell them the specific calibrations, supplier relationships, or training methods that produce it.

The schema publication is a strength, not a vulnerability. It signals operational sophistication. It creates an ecosystem of operators who speak the same specification language. It positions the publisher as the standard-setter.

Brand identity as a technical standard is not the end of competitive differentiation. It is the beginning of specification-based competition. The question shifts from “who has the best brand book?” to “who has the most comprehensive, most validated, most traceable operational specification?”

In that competition, the PDF loses.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

Toyota engineers have a word for waste: muda. Not just physical waste — wasted motion, wasted time, wasted inventory, wasted processing. Any activity that consumes resources without creating value for the customer is muda. The entire lean manufacturing philosophy is, at its core, an obsessive hunt for muda and its elimination.

Now apply that lens to branding.

A company hires a brand agency for $50,000. The agency conducts workshops, creates mood boards, delivers a 60-page brand book with color palettes, typography guidelines, tone of voice documentation, and aspirational photography. The brand book goes to the marketing team, who create advertisements, social media posts, and packaging that comply with the guidelines.

The customer walks into the store and encounters: a bored employee who doesn’t make eye contact, a product that doesn’t match the website photos, and a bathroom that hasn’t been cleaned since morning.

The $50,000 brand book is muda. Not because brand strategy is worthless, but because the brand strategy was disconnected from the operations that actually create the customer experience. The designed signals (beautiful advertisement) and the operational signals (dirty bathroom) are incoherent. The customer believes the bathroom, not the advertisement.

The branding industrial complex

The global branding industry is worth approximately $60 billion annually. This includes brand strategy agencies, identity design firms, naming consultants, brand architecture specialists, and the vast ecosystem of marketing services that turn brand strategies into communications.

What does this $60 billion produce? Primarily: designed artifacts intended to communicate to customers. Logos, color systems, typography, packaging, advertising campaigns, social media content, brand guidelines documents.

These designed artifacts represent perhaps 10-15% of the signals a business emits. The other 85-90% — every operational by-product that customers actually perceive — is unmanaged. The speed of service. The temperature of the coffee. The cleanliness of the space. The knowledge of the staff. The smell when you walk in. The sound environment. The weight of the cup. The accuracy of the order. Whether the wifi works.

In lean terms: the branding industry is overprocessing the 10-15% while ignoring the 85-90%. It is applying effort where the customer derives minimal marginal value while neglecting the areas where the customer derives most of their experience.

This is not an argument against visual identity or design quality. It is an argument about allocation of effort. If you have $50,000 to spend on “brand,” spending it on a brand book is muda. Spending it on operational specifications, barista training, equipment calibration, and interior design that customers actually experience is value creation.

Muda in branding: perception contribution versus budget allocation across signal sources. Top-spend categories create the least perception.

The signal ratio

Spectral Brand Theory measures brand perception across eight dimensions. In a physical business like a coffee shop, the signals break down roughly as follows:

Perception percentages are illustrative estimates for a physical retail business (specialty coffee), informed by service quality and customer experience research (Parasuraman, Zeithaml & Berry 1988; Pine & Gilmore 1999; Verhoef et al. 2009). Brand spend percentages represent typical SMB allocation patterns estimated from industry benchmarks — Gartner CMO Survey (2022–2024) and WARC Global Advertising Trends data consistently show 60–75% of brand budgets allocated to paid media and visual identity work, with single-digit percentages for operational quality investment. Both columns are order-of-magnitude estimates; exact ratios vary by industry, scale, and brand maturity. The structural pattern — operational signals dominate perception; designed signals dominate budget — is the consistent finding across the literature.

The mismatch is stark. 75% of the brand budget goes to signals that contribute 15% of perception. 25% of the budget goes to signals that contribute 85% of perception. This is textbook muda: massive resource allocation to low-value activities.

The lean prescription is simple: reallocate.

What the customer actually perceives

Research in service quality — from Parasuraman’s SERVQUAL to more recent experience economy work — consistently shows that customer perception is dominated by operational signals, not designed communications.

Customers form brand impressions from:

1. Product quality (does the coffee taste good?) — not from the poster that says “artisanal quality.”

2. Service behavior (was I acknowledged quickly? was the barista knowledgeable?) — not from the brand value that says “customer-first.”

3. Environmental cues (is it clean? is it comfortable? does it smell right?) — not from the interior design mood board.

4. Consistency (is it the same every time? can I rely on it?) — not from the tagline about “consistent excellence.”

The designed signals (logo, advertising) serve as promises. The operational signals serve as proof. When the proof matches the promise, the brand is coherent. When the proof contradicts the promise, the customer believes the proof.

Every dollar spent on making the promise louder while the proof stays weak is muda. It is worse than muda — it is actively harmful, because a larger promise-proof gap creates more disappointment than no promise at all.

The orgschema approach: specify the proof

The Organizational Schema Theory methodology starts from the customer experience (the proof) and designs backward. It does not start from the brand strategy (the promise) and hope that operations deliver.

Here is the difference:

Traditional brand-first approach:

1. Brand agency defines “warm, artisanal, community-focused” positioning

2. Design team creates visual identity expressing this positioning

3. Marketing team communicates the positioning

4. Operations team receives the brand book and is told to “live the brand”

5. Customer perceives: beautiful Instagram, mediocre in-store experience

6. Result: promise-proof gap, brand incoherence

Orgschema operations-first approach:

1. Define customer experience goals: “acknowledged within 10 seconds, espresso within 90 seconds, staff can explain origin of every coffee”

2. Define signal requirements: “visible craft preparation, aroma of fresh coffee at entrance, ethical sourcing displayed”

3. Define process contracts: “extraction 25-30s at 92-94C, grinder calibrated daily, cleaning every 2 hours”

4. Implement procedures, train staff, source ingredients

5. Customer perceives: consistent quality, knowledgeable staff, pleasant environment

6. Result: the brand IS the experience, no gap to manage

In the second approach, the visual identity comes last — derived from the operational reality rather than aspirationally imposed on it. The logo, the menu design, the signage all express what the business actually does, not what a brand agency imagines it should be.

This is “good branding is no branding” — not in the sense that visual identity doesn’t matter, but in the sense that the best brand strategy is an operations strategy. The brand is the operations. Design the operations well and the brand follows.

Ohno would approve

Taiichi Ohno identified seven types of waste in manufacturing. Applied to branding:

Overproduction: Producing brand communications that nobody reads. The 60-page brand book that sits on a shelf. The social media content calendar that generates engagement metrics but no business outcomes.

Waiting: The time between a brand strategy workshop and operational change. In most organizations: infinite. The brand book is produced; nothing operational changes.

Transportation: Moving brand guidelines between departments without operational implementation. The “brand alignment meeting” that produces no measurable process changes.

Overprocessing: Refining the logo for the fifteenth time while the espresso extraction is inconsistent. Perfecting the Instagram grid while the allergen management is incomplete.

Inventory: Stockpiling brand assets (photography libraries, template systems, brand portals) that cost money to maintain but produce no customer value.

Motion: The brand team and operations team in separate meetings, separate departments, separate strategic plans. The motion of coordinating what should be unified.

Defects: The promise-proof gap itself is a defect. Every advertisement that creates an expectation the operation cannot meet is a defective output that generates rework (customer complaint handling, reputation management, discount offers to disappointed customers).

Lean says: eliminate the waste, invest in the value stream. For branding, the value stream is the operational signals that customers actually perceive. Everything else is muda.

The Muji precedent

Muji — the Japanese retailer whose name literally means “no-brand quality goods” — is the best real-world example of operations-as-brand. Muji has no brand in the traditional sense: no logo on products, no advertising narrative, no brand spokesperson. Its “brand” is the consistent quality and thoughtful design of the products themselves.

Muji’s spectral profile is revealing: semiotic 9 (through absence and minimalism), experiential 8 (material honesty, functional simplicity), ideological 8 (anti-consumption philosophy). These scores come from operational decisions — product selection, material choice, store design — not from brand communications.

Muji spends approximately 0% of revenue on traditional brand advertising. Its brand value (estimated at $7 billion) is entirely derived from operational quality. This is the logical endpoint of eliminating branding muda: spend nothing on promises, spend everything on proof.

Not every business should be Muji. The point is not anti-branding absolutism. The point is that Muji demonstrates the upper bound of what operations-as-brand can achieve: a globally recognized, highly valued brand built entirely on operational signals.

The specification as brand strategy

Orgschema provides the infrastructure for operations-as-brand. When your operational specifications include satisfies_signal traceability — when every process contract links to the signals it emits and the customer experience goals those signals serve — then brand management IS operations management.

The “brand strategy” becomes: which signals do we want to emit across which SBT dimensions? What spectral profile are we targeting? This is Level 0 in orgschema: the customer experience contract with targets across eight perceptual dimensions.

The “brand implementation” becomes: what processes emit those signals? What quality gates ensure consistency? This is Levels 1-2 in orgschema: signal requirements and process contracts.

The “brand consistency” becomes: does the CI/CD pipeline pass? Are all processes meeting their quality gates? Are all quality gates connected to signals? Are all signals connected to experience goals?

There is no separate brand strategy. There is one specification, one repository, one validation pipeline. The brand is the specification. The specification is the operations. The operations are the brand.

The $50,000 brand agency fee becomes $0. The brand investment goes into better equipment, better training, better ingredients, better environment — the operational inputs that create the operational signals that create the customer perception that IS the brand.

Muda eliminated. Value created. Ohno would approve.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

Your brand strategist and your COO are solving the same problem. They just do not know it yet.

The brand strategist asks: “How should customers perceive us?” The COO asks: “How should our operations perform?” These sound like different questions. They are the same question viewed from different ends of the same causal chain. Customer perception is the by-product of operational execution. The brand IS the operations, perceived.

The brand-operations disconnect

In most organizations, brand and operations are separate functions with separate leadership, separate budgets, and separate strategic plans. The marketing team defines the brand: warm, artisan, community-focused. The operations team runs the business: grind coffee, serve customers, clean the space. The two teams meet occasionally to “align,” which means the operations team receives the brand book and is told to “live the brand.”

This separation creates the promise-proof gap. Marketing promises “artisan quality.” Operations delivers what the staff, equipment, training, and procedures can produce. When the promise exceeds the proof, customers are disappointed. When the proof exceeds the promise, the business leaves value on the table. Both failures stem from the same structural problem: brand and operations are managed as separate systems.

Orgschema eliminates this separation. Brand perception (what customers experience) is Level 0 of the TDD cascade. Operations (what the business does) is Levels 2-5. The connection between them is not a brand alignment meeting. It is a test suite: Level 0 defines what customers should perceive, Level 1 defines what signals must be emitted, and the CI/CD pipeline validates that operations (Levels 2-5) actually emit those signals.

Git log as brand history: operational commits mapping to brand perception changes across eight SBT dimensions.

Every commit is a brand decision

When someone commits a change to the operational specification, they are making a brand decision. Not metaphorically. Literally.

Change the espresso dose from 18g to 19g: this affects the taste profile, which is a signal on the experiential dimension, which contributes to the product excellence experience goal. The brand just changed.

Change the opening music playlist: this affects the sound environment, which is a signal on the semiotic dimension, which contributes to the atmosphere experience goal. The brand just changed.

Change the cleaning frequency from every 2 hours to every 3 hours: this affects the perceived cleanliness, which is a signal on the experiential dimension, which contributes to the environmental quality experience goal. The brand just changed.

In an orgschema specification, these connections are explicit. Every operational parameter has a satisfies_signal annotation that links it to the brand signal it produces. Every brand signal has a satisfies_experience annotation that links it to the customer experience goal it serves. The traceability is complete and machine-validated.

The git log, therefore, is the brand history. Not the history of logo revisions and campaign launches. The history of every operational decision that changed what customers perceive. git blame shows who made each brand decision. git diff shows what changed in the brand after each operational modification.

The signal inventory

Spectral Brand Theory measures brand perception across eight dimensions. In an orgschema specification, every operational parameter maps to at least one dimension:

Six of eight dimensions are produced by operations (Levels 2-5), not by marketing. The semiotic dimension (visual identity) is the traditional domain of brand strategy. The narrative dimension is partially specifiable but largely emergent. Everything else — the majority of brand perception — is an operational by-product.

This is the fundamental insight: brand management IS operations management. The COO is the chief brand officer, whether they know it or not. Every operational decision — from supplier selection to cleaning schedules to staff training — produces signals that customers perceive as “the brand.”

The signal audit

Most businesses have never inventoried their signals. They manage the designed signals (logo, website, advertising) and ignore the operational signals (speed of service, temperature of the coffee, knowledge of the staff, cleanliness of the bathroom).

Orgschema provides the infrastructure for a complete signal audit. For every process, product, and procedure in the specification, ask: “What does this emit that a customer might perceive?” The answer is a signal, and it maps to one or more SBT dimensions.

A signal audit for a coffee shop might reveal:

Designed signals (typically managed):

• Logo on the cup (semiotic)

• Menu design (semiotic)

• Instagram content (semiotic, narrative)

Operational signals (typically unmanaged):

• Time from order to delivery (experiential)

• Barista’s knowledge of coffee origin (experiential, ideological)

• Cleanliness of the bathroom (experiential)

• Smell at the entrance (experiential)

• Sound environment (semiotic)

• Visible craft preparation (experiential, semiotic)

• Ethical sourcing displayed (ideological)

• Pricing relative to competitors (economic)

• Seasonal menu changes (temporal)

• Staff recognition of regulars (social)

The unmanaged signals outnumber the managed signals roughly 3:1 in a typical coffee operation. And the unmanaged signals contribute approximately 85% of the customer’s total perception. The brand budget, meanwhile, is allocated roughly inverse to this: 75% on designed signals, 25% on operational signals.

Orgschema inverts this allocation by making operational signals visible, measurable, and traceable. When every operational parameter maps to a brand dimension, the operations budget IS the brand budget. Investment in better equipment, better training, better ingredients, and better procedures is investment in the brand — because it improves the signals that produce the perception.

The circular architecture

The connection between brand and operations is not one-directional. It is circular:

1. Define desired perception (L0 customer experience contracts across 8 SBT dimensions)

2. Derive required signals (L1 signal requirements: what must be emitted)

3. Specify processes that emit those signals (L2 contracts, L3 procedures)

4. Execute the processes (daily operations)

5. Emit signals as by-products of execution

6. Perceive the signals (customer experience, observer-dependent)

7. Measure the perception (SBT spectral profile measurement)

8. Compare measured perception to desired perception (L0 acceptance tests)

9. Adjust specifications where perception falls short

10. Return to step 1.

This is reverse-design TDD applied to brand management. The brand is not a static artifact (a brand book). It is a continuously validated specification that evolves through the design-execute-measure-adjust cycle. The git log captures every adjustment. The CI/CD pipeline validates every change. The spectral profile measurement closes the loop.

Traditional brand management is steps 1-5 only: define the brand, create communications, hope for the best. Orgschema adds steps 6-10: measure, compare, adjust, validate. The circular architecture makes brand management empirical, not aspirational.

The COO as brand guardian

If brand perception is an operational by-product, then the person responsible for operations is responsible for the brand. Not the CMO. Not the brand agency. The COO.

This is not an argument against marketing or design. Visual identity matters. Communication strategy matters. But these are a subset of the signals that produce brand perception. The majority of signals come from operations. The person who controls operations controls the brand.

In an orgschema organization, this convergence is structural:

• The COO owns the specification repository

• Every commit to the specification changes the brand

• The CI/CD pipeline validates that operations satisfy brand goals

• The spectral profile measurement tells the COO whether the brand is on target

There is no separate brand strategy. There is one specification, one repository, one validation pipeline. The brand strategy IS the operations strategy. The brand review IS the operations review. The brand investment IS the operations investment.

Your brand is your git log. Every commit is a brand decision. The question is not whether to manage your brand — you are managing it with every operational choice. The question is whether to do it deliberately, with traceability and validation, or accidentally, hoping the brand book and the reality converge on their own.

This article is part of the convergence series bridging Spectral Brand Theory (perception measurement) and Organizational Schema Theory (operational specification).

SBT research paper: Zenodo preprint
OST research paper: Zenodo preprint
Open-source toolkits: SBT · Orgschema

Your next most important customer might not have eyes. It will not appreciate your origin story or your aesthetic. It will not feel the warmth of your barista’s greeting or notice the hand-chalked menu board. But it will reject your API if response time exceeds 200ms. It will exclude your product if the carbon footprint field is missing from the registry. It will rank your competitor higher if their specification is more complete.

The Organizational Schema Theory was developed with human customers in mind. The entire TDD cascade — from customer experience contracts (L0) through signal requirements (L1) to sourcing (L5) — was designed to produce businesses that satisfy human perception. But it turns out the methodology is more general than that. OST is observer-agnostic: the cascade works identically whether the customer is a person, an algorithm, or a hybrid decision system.

The human assumption

All prior OST work starts from the same place: “What should the customer perceive and feel?” This is Level 0 — the acceptance test. Level 1 translates that into signal requirements across Spectral Brand Theory’s eight perceptual dimensions. The rest of the cascade (L2-L5) specifies the operations that produce those signals.

This works because human customers perceive brands through signals: the taste of the espresso, the look of the space, the speed of acknowledgment, the story of the beans. SBT models these signals across eight dimensions. OST designs backward from the desired perception to the required operations.

But what happens when the customer does not perceive? What happens when it evaluates?

Observer-agnostic cascade: shared L2–L5 specification serving both human and machine customers, diverging only at L0–L1.

Machine customers are here

Machine customers are not a future scenario. They exist today:

API-to-API commerce. Your service’s API serves another company’s algorithm. The “customer” never sees a UI. It evaluates response time, data format, error rate, and uptime. Its acceptance test is an SLA, not a perception.

Automated procurement. Enterprise procurement systems evaluate suppliers against structured criteria: price, lead time, certification status, compliance scores. The first filter is algorithmic. Humans only see what the machine shortlists.

AI shopping assistants. A consumer asks their AI: “Find me a sustainable coffee subscription under EUR 25/month with direct-trade sourcing.” The AI queries structured product data, filters against criteria, and presents options. The consumer chooses from the shortlist. The AI narrows; the human decides.

Platform algorithms. Google ranks your content. Instagram surfaces your posts. Spotify recommends your product. The algorithm is your first customer — it decides whether humans ever see you at all.

Digital Product Passports. The EU’s ESPR regulation mandates machine-readable product data. Registries, recyclers, and compliance systems consume this data. The machine evaluates. The human may never see the raw data at all.

In each case, a machine evaluates the organization’s output against formal criteria. Not perception. Not feeling. Specification matching.

What changes in the cascade

When the customer is a machine, two things change and four things stay the same.

What changes

L0 becomes a formal specification. For human customers, L0 is a perceptual target: “customers should perceive craft expertise and attention to detail.” This is fuzzy, subjective, observer-dependent. For machine customers, L0 is a formal specification: “API responds within 200ms with valid JSON matching schema v2.3.” This is crisp, deterministic, unambiguous.

The three contract types still apply:

• Experience contracts: “API returns results within 200ms” (functional satisfaction)

• Constraint contracts: “Complies with PSD2 data format” (regulatory)

• Commitment contracts: “99.99% uptime SLA” (self-imposed)

L1 collapses into L0. For human customers, L1 exists because there is a gap between what signals the business emits and what the customer perceives. SBT’s eight dimensions model this gap. Machines have no gap. The signal IS the specification. A machine does not “perceive” your API response — it evaluates it against a schema. There is no perception cloud, no observer priors, no conviction collapse. L1 as a separate level disappears.

What stays the same

L2 — Process Contracts. Still required. The process must produce outputs that satisfy L0, whether the customer is human or machine.

L3 — Procedures. Still required. Executor topology (human, machine, hybrid) on the operator side is independent of customer type.

L4 — Input Specifications. Still required. Materials, equipment, data sources.

L5 — Sourcing Requirements. Still required. Supply chain, data providers, infrastructure.

Contract-procedure separation. Still holds. The process contract does not change when you swap executor type.

Forkability. Still works. Copy the test suite, rewrite the implementation.

CI/CD validation. Still works — and actually becomes easier, because L0 acceptance tests are deterministic rather than perceptual.

The dimensional transformation

SBT’s eight perceptual dimensions do not disappear for machine customers. They transform from perceptual (how a human processes the signal) to functional (how a machine evaluates the signal):

The pattern: human dimensions have noise, subjectivity, and path-dependence. Machine dimensions are deterministic. But in both cases, the specification (L2-L5) is the same YAML.

The hybrid customer

The most commercially significant case is the hybrid: a machine filters, a human decides.

Consider the AI shopping assistant scenario. A consumer wants a coffee subscription. The interaction unfolds in two phases:

Phase 1 (machine): The AI agent queries structured product databases. It filters by: price range, delivery options, origin certifications, carbon footprint, allergen data. This is pure specification matching. Products without structured data are invisible. Products with incomplete data are excluded. The machine produces a shortlist of 3-5 options.

Phase 2 (human): The consumer sees the shortlist. Now perception takes over. The brand’s visual identity, the origin story, the packaging aesthetic, the tone of the product description, the social proof from reviews. SBT’s full eight dimensions apply. The human chooses based on perception.

The critical insight: in a hybrid-customer world, unspecified value is invisible value. Your beautiful cafe ambiance, your hand-chalked menu, your barista’s genuine warmth — none of these pass through the machine filter. They only matter if the machine lets the human see you first.

This is not hypothetical. It is how an increasing share of commerce already works. Google is a machine customer for your website. The App Store algorithm is a machine customer for your app. The procurement RFP scoring system is a machine customer for your B2B offering.

Specification-first design is not just good practice. It is the price of admission.

OST as the more fundamental framework

This analysis reveals an important asymmetry:

• OST works for all customer types (human, machine, hybrid). The TDD cascade is observer-agnostic.

• SBT works only for human customers. Its perception model (observer-dependent, non-ergodic, 8 dimensions) requires a perceiving observer.

• The SBT+OST pairing is the specialized case for human customers, where perception theory enriches the design methodology.

OST is the more fundamental framework. SBT is a specialization that adds richness when the customer is human. As machine-to-machine commerce grows — APIs, IoT, autonomous procurement, AI-mediated shopping — OST’s relevance expands independently of SBT.

This does not diminish SBT. Human customers are not going away. Most high-value experiences (hospitality, luxury, professional services, specialty food) will remain primarily human-perceived. But the entrance to those experiences is increasingly machine-mediated. The AI assistant that recommends the restaurant. The algorithm that surfaces the coffee subscription. The procurement system that shortlists the consulting firm.

The specification layer (OST) must satisfy the machine. The perception layer (SBT) must satisfy the human. Both matter. But the specification comes first — because without it, the human never sees you.

Non-ergodicity disappears

SBT’s deepest theoretical contribution is that brand perception is non-ergodic: the time average does not equal the ensemble average. Signals compound multiplicatively. Negative conviction is absorbing. The sequence of experiences matters.

None of this applies to machine customers. A machine evaluates each interaction independently (unless explicitly programmed otherwise). The API call either passes or fails. The product data either meets the criteria or does not. There is no path-dependence, no conviction accumulation, no absorbing states.

This means CI/CD validation for machine-customer organizations achieves full deterministic validation. No surveys, no perception studies, no NPS scores. The test passes or it does not. This is M5 maturity (fully validated specification) by default.

What to do now

If your business serves or will serve machine customers (and most will), the OST methodology applies directly:

1. Identify your machine customers. Which algorithms, platforms, or automated systems evaluate your output? Google, app stores, procurement systems, DPP registries, AI shopping agents?

2. Define L0 as formal specification. What does each machine customer require? Response time, data format, completeness criteria, compliance fields. These are your acceptance tests.

3. Skip L1. For machine customers, the signal IS the specification. No perception gap to model.

4. Specify L2-L5 as usual. Process contracts, procedures, inputs, sourcing. The cascade is the same.

5. Run CI/CD. Validate that your specification satisfies the machine customer’s requirements on every commit. Deterministic testing, deterministic results.

6. For hybrid customers, design both layers. The machine filter gets the formal specification (OST only). The human decision-maker gets the perceptual design (SBT+OST). Both must be specified. Both must be validated.

The specification is not optional. It is the interface between your business and every customer — human or machine — that will ever evaluate your output.

This article extends the Organizational Schema Theory to machine and hybrid customers.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

McDonald’s spent an estimated $14 billion on technology between 2019 and 2024 (based on annual reports and investor presentations citing ~$2B+ annual tech spend). They know the optimal holding time for every menu item. They know which drive-through lane configurations minimize wait time by 15 seconds. They know the exact temperature at which a french fry transitions from “crispy” to “limp” and the precise window in which it must be served.

Your coffee shop has a recipe card taped to the espresso machine that says “18g in, 36g out, 25-30 seconds.” Maybe.

This is not a fair comparison. McDonald’s has 40,000 locations and $25 billion in annual revenue. They can afford food scientists, operations researchers, and custom technology platforms. You have three employees and a lease you are not sure you can cover next month.

But what if the gap were not about resources? What if it were about methodology?

The specification gap

McDonald’s does not run better because it is bigger. It runs better because every operational parameter is specified. The holding time for a Big Mac is not a suggestion — it is a quality gate with a measurable threshold. The drive-through greeting is not “be friendly” — it is a timed interaction with defined steps. The fry oil temperature is not “hot enough” — it is 168 degrees Celsius with a documented calibration schedule.

This level of specification costs money when you build it from scratch for 40,000 locations. But the methodology — the practice of specifying operational parameters with measurable thresholds and validating them systematically — costs nothing. It is a discipline, not a technology.

The analogy is microscopes. Before microscopes, only wealthy institutions could study the cellular structure of organisms — the instruments were rare and expensive. When microscopes became affordable, any biologist could see cells. The structural level of observation changed for everyone, not just the well-funded. AI does the same for operational specification: McDonald’s-level structural resolution — where every parameter is specified, every threshold is measurable, every quality gate is defined — becomes available to any business with an LLM subscription and a GitHub account. The microscope did not create new organisms. It revealed the structure that was always there. Orgschema does not create new operations. It reveals the specification that was always implicit.

The problem is not that small businesses cannot afford to specify their operations. The problem is that no one has given them a practical methodology to do it. The tools available are either enterprise software ($100,000+ implementation) or generic business plan templates that specify nothing measurable.

The Organizational Schema Theory fills this gap. It is a design methodology that applies Test-Driven Development to business operations. You specify what customers should experience (acceptance tests), what signals the business must emit (integration tests), and what each process must achieve (unit tests) — then you write procedures to pass those tests. A validation pipeline checks consistency on every change.

The result: McDonald’s-level operational specification at coffee shop scale, for the cost of a GitHub account and an LLM subscription.

McDonald’s-grade analytical capabilities at coffee shop cost: enterprise ERP stack versus orgschema plus LLM.

What specification actually looks like

Here is the difference between an unspecified and a specified coffee operation:

Unspecified (how most coffee shops operate):

• “Make good espresso”

• “Keep things clean”

• “Be nice to customers”

• “Order more beans when we’re running low”

Specified (what orgschema produces):

espresso_extraction:
  quality_gates:
    dose_g: [17, 19]
    extraction_time_s: [25, 30]
    temperature_c: [92, 94]
    yield_ml: [28, 32]
    crema: “present, golden-brown, minimum 2mm”
  satisfies_signal: “craft_preparation_visible”
  satisfies_experience: “taste_balanced_sweet_clean”

The second version is testable. You can verify whether a shot meets spec. You can diagnose why it doesn’t (dose too high? temperature too low? grind too coarse?). You can train a new barista against measurable criteria instead of “watch Maria and try to do what she does.” You can ask an LLM “why did my 35-second shot taste bitter?” and get an answer that references your spec, not generic internet advice.

McDonald’s has this for every process in the restaurant. Your coffee shop could too.

The maturity ladder

You don’t need to specify everything on day one. Orgschema defines a maturity model — progressive steps from “nothing is documented” to “everything is tested”:

M0: Tribal knowledge. Processes exist in people’s heads. When the head barista is sick, quality drops. When they quit, knowledge leaves. This is where most small businesses live.

M1: Schema defined. You know what you need to specify, even if you haven’t specified it yet. You have a list: extraction parameters, cleaning schedule, allergen management, supplier contacts. The list itself is valuable — most businesses have never written it.

M2: Quality gates set. Each process has measurable thresholds. Espresso: 25-30 seconds. Milk temperature: 60-65 degrees. Grinder calibration: daily at opening. Now you can test whether a process is meeting standards.

M3: Procedures documented. Step-by-step instructions for how your team achieves the quality gates. This is what a franchise manual contains. The difference: your procedures are written to pass your tests, not to comply with someone else’s manual.

M4: Fully traced. Every procedure traces to a quality gate. Every quality gate traces to a signal the business should emit. Every signal traces to a customer experience goal. You know why you do everything. “Why do we calibrate the grinder daily?” Because the extraction quality gate requires 25-30 seconds, which satisfies the “craft preparation quality” signal, which produces the “balanced, sweet espresso” customer experience. Remove the justification and you remove the process — it was waste.

M5: Validated. A CI/CD pipeline runs on every change. When someone updates a recipe, the pipeline checks whether the change breaks any quality gate, signal requirement, or customer experience goal. Regression testing for your business.

McDonald’s operates at M5. Most independent coffee shops operate at M0-M1. Getting to M2-M3 is the largest single improvement most small businesses can make — and it requires no technology investment, only the discipline of writing down what “good” means in measurable terms.

The $20/month enterprise

Enterprise Resource Planning systems — SAP, Oracle, Microsoft Dynamics — cost $100,000 to $1 million to implement and $50,000 to $200,000 per year to maintain. They provide real-time transaction processing: point-of-sale, inventory management, payroll, financial reporting.

Orgschema does not replace ERP. It does not process transactions. What it does is provide the specification layer that tells the ERP what to measure and why. And for a small business that cannot afford ERP, orgschema provides perhaps 60-70% of the analytical capability at radically lower cost.

The breakdown:

A coffee shop owner who maintains orgschema specifications can ask an LLM: “What’s my highest-margin product?” “Which supplier change would affect the most customer experience goals?” “Generate a training checklist for a new barista.” “What allergens are in the oat latte?” The LLM reads the YAML — structured data it understands natively — and provides answers that reference the operator’s own specifications, not generic information.

This is not a replacement for sophisticated enterprise technology. It is a democratization of operational intelligence. The gap between McDonald’s and an independent coffee shop shrinks from “entirely different universe” to “same methodology, different scale.”

What McDonald’s actually knows

Let’s be specific. McDonald’s operational knowledge includes:

Holding times. Every menu item has a maximum holding time after preparation. A Big Mac: 15 minutes. Fries: 7 minutes. After the threshold, the item is discarded. This is a quality gate with automatic enforcement (the POS system tracks preparation timestamps).

Station layout. Every kitchen station is designed for specific motion efficiency. The distance between the grill and the assembly area is specified. The height of the counter is specified. The sequence of assembly steps is specified. This is Level 3 in orgschema terms: procedures optimized for a specific executor profile (in this case, human workers with minimal training time).

Crew scheduling. Labor is scheduled against predicted demand curves, with shift structures optimized for training time, break compliance, and station coverage. This is Level 4: input specifications for human resources.

Supply chain integration. Ingredient specifications are defined to tolerances that ensure consistency across 40,000 locations and hundreds of suppliers. The potato for fries has a specified sugar content range (it affects browning). The beef patty has a specified fat percentage. This is Level 5: sourcing requirements with measurable quality gates.

Customer experience targets. Drive-through order-to-delivery time: under 90 seconds. In-store greeting: within 5 seconds of approach. Order accuracy: 99.5%+. These are Level 0: customer experience contracts with proxy indicators.

Every one of these specifications is within reach of an independent coffee shop — not at McDonald’s scale or precision, but at a level that dramatically exceeds the current state of “make good espresso.”

The five things to specify first

If you run a coffee shop and want to start, here are the five specifications that deliver the most value per hour invested:

1. Extraction parameters. Dose, time, temperature, yield for every coffee drink. This is your core quality gate. Write it down. Test against it. When shots taste wrong, diagnose against the spec instead of guessing. Time investment: 1 hour. Impact: immediate quality consistency.

2. Allergen matrix. Every product, every ingredient, every allergen — declared and cross-contamination. This is legally required in the EU (14 allergens) and practically essential everywhere. An LLM can generate the first draft from your ingredient list in minutes. Time investment: 2 hours. Impact: legal compliance, customer safety.

3. Opening and closing checklists. What must happen before the doors open and after they close. Calibration, cleaning, stock checks, cash counts. These are the most frequently forgotten processes and the ones that cause the most inconsistency. Time investment: 1 hour. Impact: daily operational consistency.

4. Supplier specifications. For each ingredient: what you need, what the quality criteria are, who provides it, what the fallback is. When your roaster misses a delivery, having the spec means any replacement supplier knows exactly what you need. Time investment: 2 hours. Impact: supply chain resilience.

5. Customer experience goals. What should customers actually experience? Not “good coffee” but: “espresso delivered within 90 seconds, acknowledged within 10 seconds of entering, able to have a conversation without shouting.” These are your acceptance tests. Everything else exists to pass them. Time investment: 1 hour. Impact: design clarity for every other decision.

Seven hours total. No software purchase. No consultant. The result: you have moved from M0 (tribal knowledge) to M2 (quality gates set) on the maturity ladder. You are now more operationally specified than 95% of independent coffee shops in the world.

The compounding effect

Specification compounds. Once you have extraction parameters written down, training becomes faster (the spec IS the training material). Quality becomes measurable (test the shot against the spec). Diagnosis becomes systematic (which parameter is out of range?). Improvement becomes trackable (tighten the tolerances, run for a week, measure customer satisfaction).

When your specifications live in a version-controlled repository, you get an audit trail for free. git log shows every change to the espresso recipe, when it changed, and who changed it. When a customer says “the espresso used to taste different,” you can check the history and know exactly what changed and when.

When an LLM can read your specifications, you get a 24/7 operational consultant for the cost of an API subscription. Not a generic chatbot — a consultant that knows YOUR equipment, YOUR recipes, YOUR suppliers, YOUR quality standards.

McDonald’s built this capability with $14 billion and four decades of institutional learning. Orgschema makes the methodology available today, for any business, at any scale.

The knowledge was never the problem. The methodology was.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

ISO 9001 requires a quality management system. It does not specify the format. Most organizations implement it as a document management system: Word files in SharePoint, controlled by a quality manager who tracks revision numbers and approval signatures. The last full audit found three outdated procedures, two broken cross-references, and one document that nobody could locate.

What if the QMS were a git repository?

The problem with document-based QMS

ISO 9001:2015 (and the incoming 2026 revision) requires organizations to maintain documented information for their quality management system. The standard specifies what must be documented but not how. Most organizations default to Word documents because that is what they know.

This creates five structural problems:

Version control is manual. Document headers say “Rev 3, Approved by: [name], Date: [date].” Finding what changed between Rev 2 and Rev 3 requires reading both versions side by side. Finding who changed it requires checking the approval chain. Finding why it changed requires institutional memory or, more likely, asking someone who may have left the organization.

Cross-references break silently. Procedure A references Procedure B. Someone updates Procedure B and changes the section numbering. Procedure A’s reference is now wrong. Nobody notices until the audit.

Compliance verification is periodic. The internal audit happens once or twice a year. Between audits, the QMS drifts. Procedures change informally. New processes are added without documentation. The QMS represents the organization as it was at the last audit, not as it is now.

The QMS and operations are separate systems. The quality manual describes processes. The actual processes run in people’s heads, in ERP systems, in spreadsheets. The QMS documents what should happen. Whether it actually happens is verified by the periodic audit — a sample-based check that catches a fraction of non-conformances.

Nobody reads it. The quality manual exists for auditors. Staff are trained through shadowing and informal instruction. The 300-page document management system serves one customer: the certification body. This is not the intent of ISO 9001.

ISO 9001 clauses mapped to orgschema YAML files: which specification file satisfies which quality management requirement.

Git solves four of five

Version control in git is automatic, granular, and auditable:

• git log shows every change to every file, with timestamps, author identity, and commit messages explaining why.

• git diff shows exactly what changed between any two versions — not “Rev 3 replaces Rev 2” but the specific lines that were added, modified, or removed.

• git blame traces every line to the commit that last changed it. “Who set the extraction temperature to 94 degrees?” is answered instantly.

• git revert rolls back a specific change without affecting other modifications. If a process change causes problems, reverting is surgical, not wholesale.

Cross-reference integrity is checkable by a CI/CD pipeline. Every reference between files can be validated on every commit. Broken links are caught immediately, not at the next audit.

Compliance verification becomes continuous. When the CI/CD pipeline runs on every commit, the QMS is validated in real time. Not “the QMS was compliant at the last audit” but “the QMS was compliant 47 seconds ago, when the last change was committed.”

The gap between QMS and operations narrows when both live in the same specification. An orgschema specification is simultaneously the quality documentation AND the operational specification. When the barista follows the espresso extraction procedure, they are following the QMS procedure. There is one specification, not two systems.

The fifth problem — nobody reads it — requires the specification to be useful, not just compliant. Orgschema addresses this by making specifications queryable (LLMs read YAML natively) and traceable (every parameter traces to a customer experience justification, giving staff the “why” behind every “what”).

Mapping ISO 9001 to orgschema

ISO 9001 structures requirements across several clauses. Here is how orgschema’s TDD cascade maps:

The mapping is not complete — ISO 9001 has requirements for documented procedures that go beyond what orgschema currently specifies (management review records, internal audit programs, competence evidence). But the structural alignment is strong. Orgschema provides the infrastructure; ISO 9001 compliance is an achievable extension.

The 17 YAML files

The Spectra Coffee demo comprises 17 YAML specification files (plus 6 perception YAML files for the L0-L1 cascade levels). Here is how they map to a QMS:

Seventeen files that a single person can understand, that an LLM can query, and that a CI/CD pipeline can validate continuously. Compare this to the typical ISO 9001 document management system: dozens of Word files, a document register spreadsheet, a controlled distribution list, and an annual internal audit program that checks a sample.

ISO 9001:2026 alignment

The Draft International Standard (DIS) for what is expected to become ISO 9001:2026 was published in August 2025, with final publication projected for late 2026 (though ISO timelines are subject to change). The DIS introduces several themes that align with orgschema:

Digital quality management. The revision acknowledges that quality management increasingly involves digital systems. Orgschema specifications are digital-native: version-controlled, machine-readable, CI/CD-validatable.

Risk-based thinking. Already present in the 2015 revision but emphasized further. Orgschema’s backward traceability IS risk-based thinking operationalized: every parameter traces to a customer experience impact, making risk assessment structural rather than periodic.

Knowledge management. The revision strengthens requirements for organizational knowledge. Orgschema specifications ARE organizational knowledge in a managed, versioned, queryable format. When a barista quits, the knowledge stays in the repository.

Integration with other management systems. The revision facilitates integration with ISO 14001 (environment), ISO 45001 (occupational health), and sector-specific standards. Orgschema’s constraint contract framework (Session 5 addition) naturally accommodates multiple regulatory sources as parallel L0 acceptance tests.

Orgschema is not ISO 9001 compliance out of the box. But it provides the infrastructure — version-controlled specifications, cross-reference integrity, continuous validation, traceable change history — that makes ISO 9001 compliance a natural extension rather than a separate system.

The per-commit certification model

The most radical implication: if the CI/CD pipeline validates the QMS on every commit, then every commit has a known compliance state. The certification body does not need to audit the organization periodically — it can audit the repository continuously.

This is “continuous certification” — compliance verified per commit rather than per year. The git commit hash becomes the certification artifact. “Our QMS was compliant at commit a1b2c3d“ is more precise than “our QMS was compliant at the February 2026 surveillance audit.”

This model does not yet exist in ISO certification practice. But the technical infrastructure is ready. CI/CD pipelines already validate schema integrity, cross-reference completeness, signal coverage, and experience traceability. Adding ISO 9001 clause coverage checks is an engineering task, not a conceptual leap.

The certification body’s role shifts from periodic inspector to pipeline reviewer. Instead of sampling procedures during a three-day site visit, the auditor reviews the CI/CD pipeline configuration: what does it check? Are the checks comprehensive? Does the validation history show consistent compliance?

Getting started

For a QMS professional considering orgschema:

1. Start with what you have. Export your current process documentation. Use an LLM to convert prose procedures into structured YAML with measurable quality gates.

2. Add traceability. For each quality gate, ask: “What customer requirement does this serve?” Add satisfies_experience links. This is the step most QMS systems skip — and it is the step that makes quality management meaningful rather than bureaucratic.

3. Set up the pipeline. A GitHub Actions workflow that validates YAML schema and cross-references runs in minutes to configure. This gives you continuous validation for free.

4. Run both systems in parallel. Keep your existing QMS during the transition. Use orgschema for the operational specifications. When the orgschema specs are comprehensive enough, retire the Word documents.

5. Engage your certification body. Show them the repository, the pipeline, the change history. Ask whether this meets their requirements for documented information. Most certification bodies are open to digital QMS approaches — they just haven’t seen a specification-first one before.

ISO 9001 was designed for quality. Orgschema provides the infrastructure to actually achieve it — not as a document management exercise, but as a testable, traceable, continuously validated specification of how your organization creates value for customers.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

The US franchise industry generates over $827 billion annually. To participate, you pay. McDonald’s charges $2.2 million in total investment for a new location. Subway starts at $230,000. Even a modest franchise like a cleaning service runs $50,000-$150,000 in license fees alone — before you open the door.

What do you get for that money? Access to an operations manual. A brand name. Supply chain relationships. Ongoing “support” (which mostly means compliance audits to ensure you follow the manual exactly).

What if the operations manual were free? What if the brand were earned through execution rather than purchased through licensing? What if supply chain relationships were local and direct rather than mandated by corporate?

Welcome to the forkable business.

What franchises actually sell

Strip away the branding and the franchise model sells four things:

1. Operational knowledge: How to run the business. Recipes, procedures, checklists, quality standards.

2. Brand recognition: Customers know the name and have expectations.

3. Supply chain access: Negotiated relationships with approved suppliers.

4. Ongoing support: Training, auditing, troubleshooting.

The franchise fee is, at its core, a knowledge access fee. You are paying for information that someone else figured out. The ongoing royalty (typically 4-8% of gross revenue, in perpetuity) is the rent you pay for continued access to that knowledge and the right to use the brand.

This made sense when operational knowledge was expensive to develop and impossible to distribute without physical manuals and in-person training. It made sense when brand recognition required millions in advertising that only a franchisor could afford. It made sense when supply chain negotiation required purchasing power that only a large network could achieve.

Does it still make sense?

Fork depth options: what stays constant and what changes at each cascade level, from supplier-only fork to greenfield.

The franchise knowledge problem

The International Franchise Association reported in 2026 that 63% of franchise executives plan to leverage technology for operations, and 52% already use AI for franchise development — up from 23% in 2025. The industry knows something is changing. But the discussion focuses on using AI to improve the existing franchise model, not on whether the model itself is obsolete.

Consider the core economics. A franchise manual is a procedures document. It tells you how to do everything: how to prepare the food, how to clean the equipment, how to greet customers, how to handle complaints. The franchisee’s job is compliance — follow the manual, pass the audits, pay the royalties.

This creates three structural problems:

The innovation problem. Franchisees who discover better methods cannot use them. The manual prescribes the procedure. Deviation is a compliance violation. A franchisee who invents a more efficient cleaning protocol or a better customer greeting script has no mechanism to contribute that improvement back to the system — and no incentive to try, since the franchisor owns all intellectual property.

The information asymmetry problem. Economists have studied this extensively. Rubin (1978) and Lafontaine (1992) documented the fundamental tension: the franchisor knows more about the system than the franchisee, and the franchisee knows more about local conditions than the franchisor. Neither can fully verify the other’s claims. The franchise fee is, in part, a premium paid for this uncertainty.

The evolution problem. When the franchisor updates the manual, all franchisees must update simultaneously. When local conditions change (new regulation, different customer demographics, supply chain disruption), the franchisee must wait for corporate to authorize a deviation. The system optimizes for consistency at the expense of adaptability.

What if there were a model that preserved the value (operational knowledge, quality standards, brand consistency) while eliminating the structural problems?

Test suites, not procedure manuals

The Organizational Schema Theory methodology separates what must be achieved (contracts) from how to achieve it (procedures). This is borrowed directly from Test-Driven Development in software: tests define expected behavior; implementation satisfies the tests. You can refactor the code (change how things work) as long as the tests still pass.

Applied to business operations, the separation looks like this:

The contract (test):

espresso_extraction:
  quality_gates:
    extraction_time_s: [25, 30]
    temperature_c: [92, 94]
    dose_g: [17, 19]
    crema: “present, golden-brown, minimum 2mm”

The procedure (implementation):
One franchisee uses a La Marzocco Strada with a manual lever. Another uses a Victoria Arduino Black Eagle with volumetric dosing. A third uses a fully automated Eversys system. All three pass the same quality gate tests. The contract does not care how the espresso is made — only that it meets the specification.

A franchise built on orgschema shares the test suite (contracts: what each process must achieve, what signals the business must emit, what customer experience goals must be met) without prescribing the implementation (procedures: the specific equipment, methods, and workflows each operator uses).

Compliance means passing the tests, not following the manual.

What a forked business looks like

We built a demonstration of this with Spectra Coffee — a complete specialty coffee operation specified in 25 YAML files. The specification covers six levels, from customer experience goals (Level 0) through signal requirements, process contracts, procedures, input specifications, down to sourcing requirements (Level 5).

Then we forked it.

A second Spectra Coffee location in Berlin-Friedrichshain. Six parameters changed at the sourcing level: different local bakery supplier, adjusted milk delivery schedule, different opening hours for the neighborhood. Everything from Level 0 (customer experience) through Level 2 (process contracts) stayed identical. Same quality standards. Same customer experience targets. Same compliance requirements. Different implementation.

The depth of the fork determines what changes:

A traditional franchise operates at “Level 5 only” — everything is prescribed except local supplier adjustments. Orgschema enables franchising at any depth. The most interesting depth is Levels 3-5: share the quality standards (tests), let operators write their own procedures (implementation).

The economics

Let’s compare directly:

Traditional franchise (McDonald’s example):

• Initial franchise fee: $45,000

• Total investment: $1.3M - $2.2M

• Ongoing royalty: 4% of gross revenue

• Advertising fee: 4% of gross revenue

• Term: 20 years

• What you get: procedures manual, brand, supply chain, training

• What you give up: operational freedom, 8% of revenue forever, $45K up front

Orgschema fork:

• Initial cost: $0 (public repository)

• Total investment: Variable (you choose your equipment, location, suppliers)

• Ongoing royalty: $0

• What you get: test suite (quality standards, experience targets, compliance specs), CI/CD validation pipeline, LLM-queryable specifications

• What you give up: nothing (you own your implementation)

• Brand: earned through execution quality, not purchased through licensing

The franchise management software market is projected to grow from $1.7 billion to $4.5-5.0 billion by 2030-2034. Current per-location pricing runs $155-$189/month. Orgschema replaces the management software AND the franchise model itself — with a GitHub repository and an LLM subscription (~$20/month).

The objection is obvious: “But what about the brand?” McDonald’s franchisees aren’t paying for a procedures manual — they’re paying for the golden arches.

True. But consider: what built the golden arches? Decades of consistent execution against quality standards. The brand is the result of consistent specification compliance, not an independent asset. Orgschema argues that if you publish the specifications (the test suite) and operators consistently pass those tests, the brand builds itself — from earned quality, not purchased recognition.

Toyota proved this. For decades, Toyota published its production methodology — the Toyota Production System — while keeping its specific implementation parameters (takt times, supplier contracts) private. The publication strengthened Toyota’s position by creating an entire ecosystem that spoke their language. The NUMMI joint venture with GM showed that the methodology transfer worked: GM learned Toyota’s system and improved. Toyota gained nothing from secrecy and everything from openness.

What the AI changes

The franchise model’s deepest value proposition is not the manual — it’s the support. When something goes wrong at 2 AM and you don’t know why the espresso tastes bitter, you call corporate. Someone who has seen the problem before tells you what to do.

Orgschema specifications are YAML — structured data that large language models read natively. When something goes wrong at 2 AM:

“The espresso tastes bitter and extraction time is 35 seconds.”

The LLM reads the quality control specification, identifies that 35 seconds exceeds the 25-30 second quality gate, diagnoses likely causes (grind too fine, dose too high, group head temperature too high), and provides the remediation procedure from the spec. It cross-references the equipment maintenance schedule to check whether the grinder is due for calibration. It checks the bean specification to verify whether a recent supplier change might have altered grind requirements.

This is not generic internet advice. This is the operator’s own specification being traversed by an AI that understands the relationships between their equipment, their beans, their procedures, and their quality targets. It is personalized operational support derived from the business’s own test suite.

The 52% of franchise executives already using AI for franchise development are building this capability on top of proprietary, closed systems. Orgschema makes it available to everyone, for the cost of an API subscription.

The remaining franchise advantages

Honesty requires acknowledging what orgschema does not replace:

Purchasing power. A 5,000-location franchise network negotiates supplier pricing that a single operator cannot match. Orgschema does not create purchasing cooperatives. (Though: the open-source ecosystem around Linux created Red Hat, which created enterprise support revenue. Similar cooperative models could emerge around popular orgschema specifications.)

Real estate expertise. Franchise systems have sophisticated site selection models. Orgschema specifies operations, not location strategy.

Capital access. Banks lend to franchisees because the franchise model has a known risk profile. A “forked” business is a new category that lenders don’t yet understand. This is a real barrier that will take time to resolve.

Network effects. “There’s a Starbucks on every corner” is a customer acquisition strategy that a single operator cannot replicate. Orgschema creates quality consistency, not geographic density.

These are genuine advantages of the franchise model. They are also, notably, not about operational knowledge — they are about scale. Orgschema disrupts the knowledge component. The scale component requires different solutions (cooperatives, networks, shared investment vehicles).

The NUMMI lesson

In 1984, Toyota and General Motors opened NUMMI — a joint venture factory in Fremont, California, using Toyota’s production methodology with GM’s workforce. The factory went from the worst in GM’s system to the best in North America within a year.

Toyota shared the test suite. GM wrote the implementation.

Toyota lost nothing. The methodology publication created an industry that studied, taught, and evangelized Toyota’s approach. Every lean manufacturing consultant in the world speaks Toyota’s language. Every business school teaches the Toyota Production System. The “franchise fee” Toyota collected was not monetary — it was ecosystem influence.

Orgschema formalizes what Toyota did intuitively. Publish the tests. Let operators write the implementation. The test suite is the methodology. The implementation is the competitive moat. Share the former; protect the latter.

How to fork a business

For the technically inclined, the process is straightforward:

1. Clone the repository. git clone the orgschema specification of a business you want to adapt.

2. Customize Level 0. Adjust customer experience targets for your market. (Or keep them identical if you want the same brand positioning.)

3. Rewrite Levels 3-5. Write your own procedures, select your own equipment, source from your own suppliers. Your implementation, your choices.

4. Run the validation pipeline. The CI/CD pipeline checks that your implementation satisfies all quality gates, signal requirements, and experience targets.

5. Iterate. When tests fail, adjust your implementation. When you want to improve, tighten the quality gates. When the upstream specification improves, merge the improvements.

For the non-technical: hire someone who understands YAML (it is dramatically simpler than the 500-page franchise operations manual you were going to receive anyway) or use an LLM to translate between plain English and specification language. The barrier to entry is lower than reading a franchise disclosure document.

Why this works: the organization is metadata

The forking model is not just a cheaper franchise. It rests on a structural claim about what organizations actually are.

An organization is not the value it produces. It is the configuration layer that specifies how value-producing processes get instantiated. The coffee is the value. The extraction contract is the process. The organizational form — who owns the equipment, who employs the baristas, which corporate entity holds the supplier contracts, how the management hierarchy is structured — is metadata about the process. It is the configuration file, not the program.

This distinction matters because the franchise model conflates two entirely separate things: the process specification (how to make the coffee) and the organizational metadata (who makes the coffee, under what corporate structure, with what supply chain relationships). A franchise license bundles both together and charges accordingly. You cannot buy the knowledge without also buying into the organizational form. The license fee covers both the test suite and the ownership template.

Orgschema separates them. The process contracts (L0-L2) are the specification. The organizational metadata — legal structure, employment relationships, supplier contracts, brand ownership — is yours to write. Fork the process contracts. Write your own organizational metadata.

When you fork at Levels 3-5, you keep the same quality gates and customer experience targets. But you write entirely new organizational metadata: your own LLC, your own supplier relationships, your own employment structure, your own local brand identity. The process is constant. The organization is variable. Two cafes can produce perceptually identical espresso through entirely different organizational structures. This is organizational metamerism: different organizational forms, same value output.

The franchise fee, seen clearly, is a fee for two bundled products. First: access to the process specification (the operations manual, the quality standards, the training program). Second: access to the organizational metadata template (the brand license, the approved supplier network, the corporate support infrastructure, the proven legal and financial structures). Orgschema unbundles them. The process specification is free. The organizational metadata is yours to build.

The organizational form itself emits perception signals. A forked independent cafe and a franchise location of the same concept are not identical in what customers perceive — even if the coffee is technically identical. The independent operation emits on temporal, ideological, and cultural dimensions: it reads as local, owner-operated, rooted in place. The franchise emits on economic and semiotic dimensions: recognized name, predictable experience, scale-backed quality assurance. These are different spectral profiles, not better or worse. Customers who seek novelty and craft signal will respond to the fork; customers who seek familiarity and reliability signal will respond to the franchise.

This is not a bug in the forking model. It is a branding advantage. The fork operator gets to emit signals that no franchise location ever can — not because the coffee is different, but because the organizational form is different. The organization is the signal as much as the product is. Fork the process. Let the organization speak.

The question

The franchise industry’s $827 billion is built on information asymmetry: franchisors know how to run the business and franchisees pay to learn. Orgschema eliminates the asymmetry. When operational knowledge is a public test suite, the franchise fee becomes unjustifiable — not because the knowledge is worthless, but because it is free.

The question is not whether business specifications will be open and forkable. The convergence of infrastructure-as-code, declarative process management, and LLM-native data formats makes this trajectory inevitable. The question is who publishes first.

Toyota published its production system and became the most valuable automaker in the world. The first coffee chain to publish its orgschema specification will not lose customers. It will gain an ecosystem.

Fork, don’t franchise.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub

By 2027, every battery sold in the European Union will need a digital passport. By 2028, every garment. Eventually, every product. The EU’s Ecodesign for Sustainable Products Regulation (ESPR), which entered into force in July 2024, mandates machine-readable product data: materials, origin, carbon footprint, recyclability, compliance certifications. Not a brochure. Not a label. A structured data file that any system can parse.

This is the largest regulatory push toward product-as-data in history. And businesses running orgschema specifications already have it.

What the regulation requires

The Digital Product Passport (DPP) requires manufacturers to provide structured, machine-readable information about their products. The specifics vary by product category, but the core requirements include:

• Materials composition: What is the product made of? Where do the materials come from?

• Environmental footprint: Carbon emissions per unit, water usage, energy consumption across the lifecycle.

• Recyclability and repairability: Can it be recycled? How? What percentage of recycled content?

• Compliance certifications: Which standards does the product meet? When were they last verified?

• Supply chain traceability: Where was each component sourced? Through which intermediaries?

The DPP is not a label you stick on the product. It is a data structure that lives in a registry, accessible via a QR code or digital identifier on the physical product. Regulators, recyclers, consumers, and downstream manufacturers can all query it.

The timeline is aggressive. Batteries over 2kWh are first (February 2027). Textiles and apparel follow (2028). The European Commission has the authority to extend DPP requirements to virtually any product category. Consumer electronics, furniture, building materials — all are candidates.

EU Digital Product Passport flow: product with embedded specification linking to origin, certifications, and machine-readable provenance.

The compliance problem

For most businesses, DPP compliance is a new documentation burden. They need to:

1. Collect data they have never systematically tracked (carbon footprint per product, recyclability percentages, supply chain provenance).

2. Structure that data in a machine-readable format they have never used.

3. Maintain that data as products, suppliers, and processes change.

4. Validate that the data is accurate and current.

5. Submit it to a DPP registry and keep it synchronized.

This is expensive. A 2024 estimate from the European Commission’s own impact assessment projected compliance costs of EUR 3,000-9,000 per product line for SMEs. For a company with 50 product lines, that is EUR 150,000-450,000 in initial compliance costs alone, plus ongoing maintenance.

The burden is not just financial. It is organizational. DPP data spans multiple departments: procurement knows the suppliers, engineering knows the materials, sustainability knows the footprint, quality knows the certifications. No single team owns all the data. Getting it into one structured format requires cross-functional coordination that most organizations are not designed for.

What orgschema already has

An orgschema product specification is, structurally, most of what a DPP requires. Consider the espresso specification from the Spectra Coffee demo:

espresso:
  ingredients:
    coffee_beans:
      origin: “Ethiopia, Yirgacheffe”
      variety: “heirloom”
      processing: “washed”
      certification: “direct_trade”
      supplier: “Moplaco Trading”
    water:
      source: “municipal, triple-filtered”
      tds_target_ppm: 120
  allergens:
    declared: [none]
    cross_contamination_risk: [milk, tree_nuts]
  equipment:
    machine: “La Marzocco Linea PB”
    grinder: “Mahlkoenig E65S”
  process_reference: “processes/espresso_preparation.yaml”
  satisfies_signal:
    - “experiential.taste_quality”
    - “experiential.craft_preparation”
  satisfies_experience:
    - “experience.product_excellence”

This is not a DPP. But it contains: ingredient origin, processing method, supplier identity, allergen declarations, equipment specifications, and traceability to quality goals. The gap between this specification and a DPP-compliant data structure is a format conversion, not a new data collection exercise.

An orgschema specification for a physical product — a chocolate bar, a garment, a battery — would be even closer. The TDD cascade naturally captures:

• L5 (Sourcing): Supplier identity, origin, certifications, transport method

• L4 (Inputs): Raw materials, composition percentages, recycled content

• L3 (Procedures): Manufacturing processes, energy consumption per step

• L2 (Contracts): Quality gates, compliance thresholds, testing requirements

• L1 (Signals): What the product communicates to the customer (sustainability, quality, provenance)

• L0 (Experience): Customer perception goals AND regulatory requirements (constraint contracts)

The DPP draws from L5, L4, L3, and L2. An orgschema specification contains all of these by design — because the methodology requires tracing every operational parameter back to its justification, whether that justification is customer experience or regulatory compliance.

The DPP as a constraint contract

In orgschema’s L0 architecture, regulatory requirements are constraint contracts — first-class acceptance tests that sit alongside customer experience contracts. The DPP is a constraint contract: it specifies what data the product must carry, in what format, validated to what standard.

constraint_contracts:
  eu_dpp:
    regulation: “ESPR (EU) 2024/1781”
    applies_to: “all products sold in EU”
    requires:
      - materials_composition
      - carbon_footprint_per_unit
      - recyclability_percentage
      - supply_chain_provenance
      - compliance_certifications
    validation: “annual audit + continuous CI/CD”
    effective_date: “2027-02-01”  # batteries

This constraint contract propagates downward through the TDD cascade. L1 signal requirements specify what data must be visible. L2 process contracts specify what measurements must be taken. L3 procedures specify how measurements are performed. L4 input specifications define the data collection requirements for each supplier. L5 sourcing requirements define what documentation suppliers must provide.

The entire chain is traceable. When a regulator asks “how do you know the carbon footprint of this product?”, the answer is: follow the chain from L0 (the constraint contract) through L2 (the measurement process contract) to L3 (the calculation procedure) to L4 (the input data) to L5 (the supplier documentation). Every link is explicit. Every link is testable.

Continuous certification vs. annual audit

The DPP regulation assumes periodic compliance verification. A product’s passport data is submitted, audited, and certified at intervals. Between audits, the data may drift from reality. A supplier changes, a material substitution occurs, a process is modified — the DPP data becomes stale until the next review.

Orgschema’s CI/CD pipeline changes this model fundamentally. Because product specifications are version-controlled and validation runs on every commit, DPP compliance is verified continuously:

Commit: “Update coffee bean supplier from Moplaco to Kerchanshe”
​
CI/CD pipeline runs:
  - Schema validation: PASS (all required DPP fields present)
  - Cross-reference validation: PASS (supplier in approved list)
  - Contract satisfaction: PASS (origin certification matches L2 requirement)
  - Signal coverage: PASS (provenance signal still satisfied)
  - Experience traceability: PASS (L0 constraint contract still met)
  - DPP export: GENERATED (updated passport data ready for registry)

The supplier change triggers automatic revalidation of DPP compliance. If the new supplier lacks a required certification, the pipeline fails. The non-compliant change never reaches production.

This is continuous certification. Not “we checked in January and it was fine.” Instead: “every change to the product specification is validated against DPP requirements before it takes effect.” The audit trail is the git log. The proof of compliance is the CI/CD pipeline history.

When AI agents shop for your customers

The DPP creates an interesting second-order effect: machine-readable product data enables machine-mediated purchasing.

Today, a consumer reads a chocolate bar’s label: “70% cacao, single origin, UTZ certified.” They make a judgment based on what they can see, remember, and compare in the moment. The information is designed for human eyes — limited, formatted for a physical label, impossible to query at scale.

With DPP data available in structured registries, an AI shopping agent can do something different:

“Find me a chocolate bar with: cacao content above 65%, single origin from West Africa, Fair Trade or equivalent certification, carbon footprint below 2kg CO2e per bar, recyclable packaging, and a price under EUR 4.”

The AI agent queries DPP registries, filters against the criteria, and returns options ranked by match quality. No label reading. No brand recall. No shelf position advantage. Pure specification matching.

This is a machine customer — an algorithm evaluating products against formal criteria. OST’s TDD cascade is observer-agnostic: it works identically whether the customer is a human perceiving signals or a machine evaluating specifications. For the AI agent, L0 is a formal query (price, carbon footprint, certification). L1 collapses — the specification IS the signal. L2-L5 are unchanged. The business that specifies its products in orgschema is already serving this customer.

For businesses with orgschema specifications, this is natural. Their product data is already structured, already queryable, already tested against quality gates. The DPP export is one more rendering of the same source of truth. The AI agent that queries the DPP registry is consuming the same data structure that the business’s own CI/CD pipeline validates.

For businesses without structured specifications — those scrambling to comply with DPP requirements by manually filling out forms — the AI shopping future is a threat. Their product data is manually entered, periodically audited, and potentially stale. The AI agent’s query may return inaccurate results. Or worse, may not return their products at all because the data is incomplete.

The product-as-API pattern

The DPP is one instance of a broader pattern: the physical product is becoming an interface to a data structure.

A barcode was the first step: a pointer from the physical product to a database record. The QR code expanded the pointer to a URL. The DPP expands the URL to a structured data API. The product’s physical form and its digital specification become two representations of the same entity.

Orgschema specifications are the source of truth behind both representations. The physical product (a cup of espresso, a chocolate bar, a battery) is one rendering — consumed by the customer’s senses. The DPP data is another rendering — consumed by registries, AI agents, and regulators. The packaging label is a third rendering — a human-readable subset of the full specification.

orgschema specification (source of truth)
  |
  +-- Physical product (sensory rendering)
  |
  +-- DPP registry data (regulatory rendering)
  |
  +-- Packaging label (human-readable rendering)
  |
  +-- API endpoint (machine-readable rendering)
  |
  +-- Training module (procedural rendering)

One specification. Five renderings. Zero manual translation between them. When the specification changes, all renderings update. When a rendering is inconsistent with the specification, the CI/CD pipeline catches it.

This is the same pattern that design tokens established for visual identity: one source of truth, multiple consumers. Orgschema extends it from colors and typography to the entire product — its composition, its process, its compliance, its environmental impact, its customer experience goals.

The competitive timeline

The DPP regulation creates a clear timeline of competitive advantage:

2024-2026 (preparation phase): Businesses that already maintain structured product specifications (orgschema or equivalent) need only build a DPP export layer. Estimated effort: days. Businesses without structured specifications begin the data collection, cross-functional coordination, and tooling investment. Estimated effort: months.

2027-2028 (compliance phase): DPP requirements take effect for batteries, then textiles. Compliant businesses trade normally. Non-compliant businesses face market access restrictions for EU sales. Orgschema businesses have continuous certification; traditional businesses rely on periodic audits.

2029+ (AI commerce phase): Machine-mediated purchasing becomes mainstream. AI agents query DPP registries to filter and rank products. Businesses with rich, accurate, continuously validated product data are discoverable. Businesses with minimal compliance data (just enough to pass the audit) are invisible to sophisticated queries.

The competitive advantage compounds. Early investment in structured product specifications pays dividends across compliance, discoverability, and operational efficiency. Late investment — scrambling to comply with each new regulation as it arrives — is perpetual catch-up.

What to do now

For businesses that have not yet started DPP preparation, orgschema provides a path that solves more than just regulatory compliance:

Step 1: Specify one product. Pick your highest-volume product. Write its specification in YAML: ingredients, materials, sourcing, process, quality gates. This takes a few hours and produces immediate clarity about what you know and what you do not know about your own product.

Step 2: Add constraint contracts. Identify the regulatory requirements that apply: DPP fields, allergen declarations, safety certifications, environmental disclosures. Add them as L0 constraint contracts. Now your specification serves two masters: customer experience and regulatory compliance.

Step 3: Trace backward. For each DPP field, trace backward through the cascade: what process produces this data (L2-L3)? What inputs are needed (L4)? What must suppliers provide (L5)? The gaps become visible. The data collection requirements become specific.

Step 4: Automate validation. Put the specification in version control. Add a CI/CD pipeline that validates DPP completeness on every change. Now your compliance is continuous, not periodic.

Step 5: Export to DPP format. Build the format conversion from your specification to the DPP registry schema. This is the last step, not the first — because the hard work is having accurate, structured product data, not converting its format.

The DPP is coming. For orgschema businesses, it is already here.

This article is part of the Organizational Schema Theory series.

Research paper: Zenodo preprint
Open-source toolkit: GitHub