Chapter 4 — SADIE: A Governed Module
"A band should be able to say 'we want to tour Texas in September' and inherit a plan — not be handed a blank project and told to be careful."
Laws most engaged: VI (Platforms Remove Decisions), II (Constraint Management).
A platform within a platform
SADIE — Stage Assistant for Duties, Itineraries, and Engagements — is Ampriot's operational layer: a workflow assistant that helps bands plan tours, book venues, arrange lodging, prepare press, release music, and follow up after shows. It is a module within Ampriot, sharing its truth store, its event spine, and its governance, and it is the clearest expression in this volume of Volume I's Law VI — Platforms Exist To Remove Decisions.
The design principle SADIE states for itself is that it is a workflow manager first — not a chatbot, not an AI feature, but a durable orchestration engine. That ordering matters, because it locates the value where Law VI says it belongs: not in any one capability, but in the hard, recurring, easily-botched decisions the module makes once so that every band inherits them.
The decisions SADIE removes
Consider what a band must decide, unaided, to run a tour. How to structure the planning. What tasks a tour needs and in what order. What information must be gathered before outreach can go out. What must be approved before anything is sent to a venue. What to do when a piece of information is missing. Each of these is a decision, and — per Law VI's arithmetic — decisions left to every band, made under the pressure of an actual tour, will be made inconsistently and often wrongly.
SADIE removes them. It ships workflow templates for the recurring processes — tour planning, local show planning, venue outreach, release marketing, post-show wrap-up — each encoding the structure, the task graph, the dependencies, and the gates that a well-run version of that process requires. A band instantiates a template ("Texas, September") and inherits a structured, governed process it did not have to design. The hard decision — how to run this kind of work well — was made once, in the template, and is now the default. That is Law VI exactly: the right thing is what the band gets without having to choose it.
The addon framework: capability without re-decision
SADIE's capabilities — venue outreach, hotel research, press outreach, release marketing, post-show wrap-up — are implemented as addons behind a stable interface, and this is Law VI operating at a second level. The core workflow engine does not hard-code "how to do venue outreach." It knows only what an addon is: what it can do, what inputs it requires, what actions it proposes, whether those actions need approval, and what it returned.
This is also a clean instance of Law II (Constraint Management). The addon interface is a chosen, enforced constraint — every capability must express itself through the same Inspect / Prepare / Execute contract — and that constraint buys the platform a property: capabilities can be added, governed, enabled, and disabled uniformly, without the core changing. The constraint that the core may not know about any specific addon is exactly what lets addons proliferate safely, the same way CapBan's trait boundaries (Volume I, Chapter 2) let its backends proliferate. The platform removes the decision of "how do we add a new capability safely" by making the addon contract the only way to add one.
The three-phase addon contract is itself a governance structure worth noting. Inspect reviews context and reports readiness, missing inputs, and possible actions — no side effects. Prepare produces draft work products — outreach copy, shortlists, itineraries — still no external side effects. Execute performs an approved action. The phases separate thinking from doing, and the separation is what makes the approval gate (Chapter 5) possible: SADIE can inspect and prepare freely, because nothing leaves the system until execute, and execute is gated.
The readiness engine: knowing what is missing
A subtle but important piece of SADIE is its readiness engine — a deterministic system that scores how ready a band or a workflow is, by category (identity, contact, EPK, riders, roster, money, schedule, travel, show, marketing, rights), and surfaces what is missing.
This is Law VI again, in a quieter form. Knowing "what do I still need before I can send this venue an offer?" is a decision SADIE makes for the band rather than leaving them to discover the gap after the fact. The readiness engine encodes, once, the knowledge of what each kind of work requires, so that every band inherits a checklist derived from their actual data rather than having to remember it. And it is deterministic — the same data yields the same readiness — which keeps it debuggable and makes it plainly a function of truth, owning nothing (the same discipline as the recommendation engine in Chapter 2).
It is also the bridge to Law V (Chapter 5): when the readiness engine finds a required input missing, SADIE does not guess it. It raises a blocker and creates a data_request task that names exactly what is needed. The platform's default behavior in the face of missing information is to ask, not to fabricate — which is where Law VI (the safe default) meets Law V (evidence before intelligence).
Governing the rails: configurability and kill switches
A platform that removes decisions must, per Law VI's second corollary, keep those decisions governable and permit deliberate deviation. SADIE does both. Its concentrated decisions are adaptable: approval modes, addon enablement, per-organization settings, preferred vendors, blackout dates, and tone are all configurable, so a band can adjust the defaults to its situation without re-deriving the whole process. And the rails remain under control: Site Admin can enable or disable SADIE globally or per organization, and enable or disable individual addons the same way.
Those last controls are kill switches, and they connect to the platform-wide module registry (Chapter 6) and to Law VII. The point here is that SADIE removes decisions as defaults, not as a prison: the right thing is what you get automatically, deviation is possible and visible, and the whole module can be governed or stopped by those who own the rails. That balance — remove the decision, keep it governable — is precisely what Volume I, Chapter 6 said separated leverage from a straitjacket.
What SADIE demonstrates
SADIE is Law VI built into a product's operational layer. It removes the hard, recurring decisions of band operations by making them once — in workflow templates, in an addon contract, in a readiness engine — and embedding the right answers as defaults a band inherits rather than designs (Law VI). The addon interface and the three-phase contract are enforced constraints that buy uniform governance and safe extensibility (Law II). The readiness engine knows what is required and, finding it missing, asks rather than guesses (Laws VI, V). And the whole module stays configurable and killable, so its concentrated decisions remain governable (Law VI's second corollary).
There is one decision SADIE removes that deserves a chapter of its own, because it is where the operational layer touches the irreversible world: the decision of whether something may be sent. No email reaches a venue, no booking is made, no public post goes out without an approval. The next chapter takes up SADIE's approval gate and its discipline of honest, grounded automation.