Reading · The Field Manual
How Bedrock works in the field.
This is the working handbook we hold ourselves to inside a client’s operation: what we do, what we write down, and how we decide the work is finished. If you run a company, the parts that matter to you are the commitments: what you decide, what you own, and what “done” means before we leave. The rest is for practitioners, in our working vocabulary.
How to read this manual.
Every statement that follows carries one of four marks. They separate what we hold to, what we currently do, what we are trying, and what we cannot yet answer.
- Doctrine
- Established Bedrock principle, held in the Canon. Argue with evidence, not preference.
- Practice
- How Bedrock currently operates. Stable, but revisable on experience.
- Proposed
- A proposed operating standard. Extends the Canon; a working model, not settled doctrine.
- Open
- A question the discipline cannot yet answer. Treat no answer as settled.
Six statements carry the company.
1
The constraint has moved.
Machine intelligence is abundant and cheapening. What remains scarce is the capacity of organizations to absorb it. The constraint is no longer intelligence; it is deployment.
2
Organizations become AI-native by changing how they operate.
Not by adopting models. An organization can consume enormous machine intelligence at the task level and remain structurally identical to its 2019 self. AI-native is an architecture, not a level of consumption.
3
The operating model is the unit of change.
The actual system by which an organization converts situations into outcomes — who notices, who decides, what escalates, what good enough means. Most of it is undocumented and held in people. Any improvement that leaves it untouched will be absorbed by it.
4
Bedrock works inside real operations.
The operating model is visible only from inside, in the work as done. Fieldwork is not the preliminary to the work. It is the work.
5
Bedrock leaves running systems.
Not recommendations. An engagement ends with production systems in use, run under the terms agreed at the start: the client operates independently, keeps us alongside, or continues on licensed technology. If the work could be fully expressed in a document, it was the wrong work.
6
Every deployment improves the next one.
Each engagement turns two loops: the client’s, which stays with them and compounds, and the discipline’s, by which patterns — stripped of everything particular — are earned into shared doctrine and platform.
Bedrock works inside real organizations to turn hidden operating knowledge into production systems. Each deployment strengthens a shared discipline, and repeated patterns become platform capabilities and products.
Final clause governed by the productization gate — products only after repetition.
Decision rules, not aspirations.
Written down so they can be taught, argued with, and enforced against us. Each: the rule, what it means in practice, and the sign it is being violated. The full statements and cases are in Volume I of the Canon.
01The operating model is the unit of change
Tools change tasks. Only operating models change outcomes.
In practiceScope every intervention to a loop, never to a task. Before building anything, name what changes in who decides, what escalates, and what is measured.
The sign it is being violatedThe demo impresses; throughput, cost, and quality do not move. The work waits faster at the same queue.
02Reality is senior
When the documentation and the work disagree, the work is right.
In practiceDesign only from observed work. Treat workarounds as data, never as non-compliance to be corrected.
The sign it is being violatedA design cites the SOP or an interview rather than observed decisions. The map was drawn in a conference room.
03Nothing is learned until it runs
Understanding is validated in production or not at all.
In practiceShip into a bounded slice of live operations early. Hold every pre-production insight as provisional.
The sign it is being violatedWeeks of artifacts and rising conviction, while nothing yet touches a live case.
04Exceptions are the curriculum
Real intelligence is visible in how the organization handles what the rules don’t cover.
In practiceBegin mapping at the exception clusters. Log every exception with its resolution and the reason it was resolved that way.
The sign it is being violatedExceptions dismissed as noise or user error. A design with no first-class exception path.
05Judgment is captured in flight
Tacit knowledge is captured by instrumenting real decisions, not by asking people to describe them.
In practiceInstrument live decisions — situation, action, reasoning, outcome. Use interviews only as the stated register, to be checked against traces.
The sign it is being violatedThe captured “rules” came from a workshop, and they are clean, complete — and wrong.
06Memory before intelligence
An organization that cannot remember cannot learn, whatever its tools.
In practiceMake the first system the decision record beneath the automation the client asked for, not the automation itself.
The sign it is being violatedReasoning is being added to an operation with no durable record — a brilliant newcomer, every morning.
07Leave systems, not slides
Every engagement must leave running systems that keep learning after we step back.
In practiceIf the deliverable can be fully expressed in a document, redo the work. Test every engagement by what is still running — and improving — a year later.
The sign it is being violatedThe plan ends in a readout. Adoption depends on our continued presence.
08Abstractions are earned
Generalize from patterns reality has repeated, never from patterns we expect.
In practiceRecord candidates with provenance and wait for recurrence. Never build platform from a single deployment’s shape.
The sign it is being violatedA roadmap running ahead of field evidence. The phrase “we’ll need this eventually.”
09Compounding beats heroics
A small gain that is retained outperforms a large gain that evaporates.
In practiceChoose the improvement that persists over the one that impresses. Install the evaluation loop beside every win.
The sign it is being violatedResults depend on one person’s continued effort, and decay the quarter attention moves elsewhere.
10Machines hold the middle; people hold the ends
Automate throughput, recall, and consistency. Reserve purpose, exceptions, and accountability for people.
In practiceFor every automated decision class, name the accountable person, the policy owner, and the escalation path above the bounds.
The sign it is being violatedA consequential decision with no named owner. Volume moved to the machine — and authority quietly went with it.
11Trust is an engineering property
Systems earn authority by being bounded, inspectable, and reversible.
In practiceSet the evaluation gate for each expansion of authority before the evidence arrives. Widen only against the record, one reversible step at a time.
The sign it is being violatedAuthority expanded because a demonstration went well.
12Bet on what does not change
Build for the decade, on assumptions that survive every model generation.
In practiceIsolate anything a model generation could obsolete behind a swappable interface. Keep memory, policies, and traces engine-independent.
The sign it is being violatedA model upgrade requires a rebuild. Today’s model limits are hard-wired into the structure.
When a future decision conflicts with a principle, one of the two is wrong — and finding out which is the most important conversation in the company.
Observe, Map, Design, Deploy, Learn.
The same work as Identify, Define and Ship, at working resolution. Run in order, and then run again. What never moves is the order beneath both: observation precedes intervention.
1 · Observe
see the work as done
- Key questions
- What decisions actually occur here? Where do the stated and the enacted disagree? What is the whole distribution — and its tails?
- Required activities
- Embed in the operation. Record live decisions. Collect all three registers — stated, enacted, revealed. Let exceptions accumulate. Propose nothing.
- Required outputs
- Observation log · decision inventory · engagement journal, open from day one.
- Exit criteria
- New cases stop surprising — the distribution’s shapes repeat. Judged on evidence, not the calendar; the likely range is stated up front.
- Failure modes
- Designing while observing. Interviewing instead of watching. Sampling the center and missing the tails. Leaving on schedule instead of on evidence.
2 · Map
find where judgment sits
- Key questions
- Where does the operation vary? Who is consulted off-chart? What slows when one person is away? Which decisions carry consequence?
- Required activities
- Study exceptions first. Follow the questions to the people they converge on. Read absence as a probe. Build the vocabulary from observed decisions, never from a glossary. Place decision types on frequency × consequence.
- Required outputs
- Operating-model map · first-cut shared vocabulary · decision map with candidates for what the system may decide · exception register.
- Exit criteria
- The map is right where the redesign will touch, and honest about its coarseness everywhere else. Fidelity before resolution.
- Failure modes
- Uniform resolution everywhere. Mapping the process instead of the judgment. Importing shapes from the last industry.
3 · Design
redesign the workflow
- Key questions
- Which decisions run automatically, which are proposed, which stay with a person — and which are deliberately left alone? What must be remembered, and where did each fact come from? How does an exception reach a person with context? What gates each expansion of authority?
- Required activities
- Place every consequential decision type. Specify the record before automation. Preserve the exception path. Design handoffs deliberately. Name the evaluation gates before the evidence arrives.
- Required outputs
- Decision architecture · record design · exception paths · evaluation plan · explicit bounds per component.
- Exit criteria
- Every consequential decision type has a home, an owner, a trace and an exception route — and the evaluation that will judge it exists before deployment does.
- Failure modes
- Placing decisions by what is easy for a machine. Automation before the record. A design with no exception path. Broad authority by default.
4 · Deploy
run it alongside people
- Key questions
- Where is evidence cheapest — high volume, low cost of a mistake? Where does the shadow run disagree with the people, and which kind of disagreement is it? Are the surprises declining?
- Required activities
- Choose the first site by how fast it teaches, not by importance. Run in shadow before granting authority. Classify every disagreement: design defect, or discovery about the operation. Expose the reasoning. Change the workflow, keep the surface.
- Required outputs
- A running system with bounds and traces · disagreement analyses · a record of surprises · decision records accumulating.
- Exit criteria
- Surprises declining. Authority expanded only through pre-named gates. The operation runs the workflow as we step back.
- Failure modes
- Starting at the most important site. Authority before shadow. Answers without visible reasoning — worked around, not adopted. Treating a surfaced flaw as failure, when it is the yield.
5 · Learn
hand over, write it down
- Key questions
- Does the client’s workflow run without us? What recurred that we have seen before? What surprised us? What must not leave the client’s walls?
- Required activities
- Verify the workflow runs client-owned. Write the outcome record — honest, including what did not work. File vocabulary and doctrine proposals with their evidence. Record pattern candidates, stripped of particulars. Complete the handoff and ownership record.
- Required outputs
- Outcome record · vocabulary proposals · doctrine proposals · pattern candidates · handoff record.
- Exit criteria
- The definition of done: the client’s workflow runs without us, and the learning has been captured.
- Failure modes
- Capture deferred until time allows — none ever does. Learning trapped in client vocabulary. Generalizing from one instance. Keeping what is the client’s.
The unit that owns a deployment.
Small, embedded, interdisciplinary, autonomous within doctrine, accountable end to end. Handoffs lose context, and context is the whole asset — so the people who did the observing do the design, and the people who did the design do the deploying and evaluating. Bedrock is early: a pod may be one or two people plus the client’s own operators. Responsibilities are defined; titles can wait for scale.
What it owns
- The whole traverse — Observe through Learn — for one deployment.
- The field instruments and their currency: contemporaneous, not reconstructed.
- The design and its bounds — the partition, the memory, the exception paths, the evaluation gates.
- The running system until handoff, and the handoff itself.
- The outcome record — honest, including what did not work.
- The capture that completes the deployment.
- The relationship with the people who run the operation — legibility is the pod’s first deliverable.
The client decides, always
These decisions remain the client’s, always. Purpose and priorities. Policy above the bounds. Disposition of exceptions above threshold. Every expansion of system authority — go or no-go at each pre-named gate. Ownership of their data, systems, and operating knowledge. And whether the partnership continues.
Capture is not clerical work.
Proposed operating standard
It must be contemporaneous — fidelity falls with the delay between observation and record — and it must be protected, because capture competes with delivery and delivery always feels more urgent. The consolidated kit below is a proposed operating standard.
- Deployment journal
- Dated, contemporaneous record of what was done, decided, and noticed. Kept daily from day one.
- Observation log
- Observed decisions and cases — above all, every case that surprises the design. Situation in, action out; register; source; date.
- Decision map
- The operation’s decision types placed by frequency × consequence, with their real holders.
- Operating-model map
- The recovered loop: judgment sites, human routers, exception clusters, handoffs. The client holds the finished definition.
- Ontology
- The explicit vocabulary the operation acts on — drawn from observed decisions, never a glossary. The client owns the content.
- Exception register
- Every case the rules did not cover, with resolution and reasoning. Stays with the client.
- Decision records and traces
- The production memory: inputs, policy version, actor, action, outcome, provenance. Built before automation.
- Evaluation plan
- What better means here and how it will be measured — written before anything runs, with the client’s sign-off on intent.
- Outcome record
- What actually happened, against intent. The honest result, not the sales version.
- Ontology proposals
- New terms for decision shapes the shared vocabulary could not yet name — client particulars stripped.
- Doctrine proposals
- Candidate abstractions, submitted with their evidence to a review that tries to refute them.
- Reusable-pattern candidates
- Recurring solution shapes worth tracking toward platform: the shape, where seen, what varied.
- Handoff and ownership record
- Who owns what when we step back. Each consequential decision → a named person.
Every captured observation carries its provenance: where, when, how many instances, and what would have falsified it. An observation without provenance is an anecdote — and anecdotes are not admissible.
Completion is defined by capture, not delivery.
A deployment is not complete because software shipped. Shipping is the midpoint. Completion has two halves, and missing either leaves the deployment half-finished, whatever the demo looked like.
The client’s half — a running, owned, evaluable operation
- In production, on real cases, at the operation’s actual volume — not a pilot enclosure.
- A named person owns every consequential decision. A name, not a role.
- Decision boundaries are explicit: what the system does alone, proposes, must escalate — written down and enforced by the system itself.
- The exception path works — and feeds back into policy.
- Context and provenance are retained: any consequential decision can be explained months later, under the policy that governed it.
- Outcomes can be evaluated: baseline recorded, outcomes measured against intent, the surprise rate instrumented.
- The client operates it without us in the room — an observed week of unassisted operation.
- The client retains its intelligence and its systems: data, vocabulary content, operating knowledge, running infrastructure, in its control.
Bedrock’s half — the learning has entered the discipline
- Non-client-specific learning is captured, with provenance.
- Candidate patterns are recorded — not promoted. Nothing declared doctrine from one instance.
- The outcome record is honest, including what did not work and what remains at risk.
- Handoff and ownership are complete. Nothing still routes through the pod.
A deployment is finished — as finished as anything in a living operation gets — when it is teaching at a declining rate. The surprise rate never reaches zero, and it should not. An operation that never surprises its designers has stopped meeting reality.
What is the client’s, and what Bedrock carries forward.
Theirs: their data, their operating knowledge, their systems in their control, the content of their vocabulary, and the implementation built around their operation. Ours: the reusable technology we bring to the next engagement — recurring decision architectures, components and scaffolds, improvements to the method, structures without their fillers, evaluation patterns, and failure modes worth not repeating — licensed where a client’s system uses them. Which is which is settled in the agreement, not by a slogan.
Proposed · four tests
| Test | The question | If it fails |
|---|---|---|
| Reconstruction | Could anyone reconstruct the client’s operation, customers, economics, or people from this artifact? | It stays with the client. Whole. |
| Substitution | Replace every client term with schema terms. Does the pattern’s value survive? | If not, it was client knowledge wearing a pattern’s costume. It stays. |
| Disclosure | Would we show the client this exact artifact, labeled as what we keep? | If not, it stays. |
| Independence | Is the shape supported beyond this one client? | If not, hold it as a candidate. Carry nothing seen once as knowledge. |
Numbers travel as classes, not values. A client’s outcomes belong to the client. What generalizes, when it does, is the shape of the result — never the figures.
Promotion is earned at every step.
Seven tiers, from one organization’s solution to a repeatable offering. Movement up the ladder is earned by recurrence and review — never by enthusiasm, and never by the existence of working software.
| Tier | What it is | Promoted by |
|---|---|---|
| Custom deployment | Built for one organization. Most work lives here, by design. | The default. Nothing to earn. |
| Observation | Something encountered in the work. | Recorded contemporaneously, with provenance. |
| Candidate pattern | A recurring shape worth tracking, stripped of local costume. | A second independent sighting. Still not knowledge. |
| Doctrine | A supported generalization that has survived the attempt to break it. | Recurrence across three or more independent deployments, then review whose task is to refute. |
| Platform capability | Reusable infrastructure implementing an established need. | Demand-pull from earned doctrine — never roadmap-push. |
| Product candidate | A repeated customer problem that might support a packaged offering. | The same costly problem registered across organizations. Tracked, not built. |
| Product | A repeatable application with a stable buyer, outcome, deployment model, and shared core. | All nine gate criteria. No exceptions. |
Tiers six and seven are proposed extensions of the Canon.
Generalizing too early — the warning signs: the abstraction preceded the third instance; the “pattern” is one client, told three times; the roadmap names capabilities no deployment has demanded; a product name exists before a second buyer does.
Thirteen questions to hold against live work.
13 questions to hold against live work, grouped by when they are asked.
Before you build
- Are we changing a task or the operating model?
- Have we observed the work as done — not the SOP, not the interview?
- Where does judgment actually sit? Named people, at the variances.
- What do the exceptions reveal? If you cannot say what they teach, observation is not done.
While you design
- What must be remembered — decisions, basis, provenance, outcome — retrievable at the moment of need?
- What authority belongs to the machine? The frequent and bounded, reversible, traced, earned through gates named in advance.
- What authority must remain human? The ends: purpose, exceptions above threshold, relationships, accountability. A name, not a role.
While it runs
- Can every consequential output be traced — inputs, policy version, outcome — months later?
- What outcome will tell us whether this worked? Named before deployment, measured against a recorded baseline.
Before you leave
- What remains running after we leave? The loop, client-owned.
- What did this deployment teach the client? Their loop turns without us.
- What did it teach Bedrock? Proposals filed with provenance; patterns recorded and left unpromoted until they recur.
- Are we generalizing from evidence or enthusiasm? Fewer than three independent instances: it is a note, not a pattern.
The essential terms.
- adaptation debt
- The widening gap between how an organization operates and how it could operate at current capability prices.
- AI-native
- An operating model in which machine cognition is a first-class participant in the loops; an architecture, not a level of consumption.
- decision architecture
- Which decisions live where, at what latency, with what oversight, leaving what trace.
- deployment gap
- The distance between what machine intelligence can do and what organizations actually do with it.
- doctrine
- Reusable understanding that survived recurrence and refutation review; provisional, versioned.
- exception path
- The first-class channel by which a case no policy fits reaches a person with context, and its resolution feeds back into policy.
- human router
- A person through whom disproportionate context flows, off the org chart; probed by absence.
- ontology
- The explicit vocabulary an operation acts on: entities, relations, decision types, exception types. Schema is universal; content is the client’s.
- operating model
- The actual system by which an organization converts situations into outcomes; exists whether or not documented.
- organizational intelligence
- An organization’s accumulated, operational capacity to convert situations into good decisions.
- partition
- The placement of every decision type: policy, proposal, judgment, or deliberately left alone.
- pod
- The small, embedded, interdisciplinary team that owns one deployment end to end.
- reversibility budget
- The amount of irreversibility a design will tolerate; spent deliberately, never accumulated by neglect.
- rule of three
- Once is a solution; twice a coincidence worth noting; three times a pattern, and only then an abstraction.
- shadow-running
- A new decision path sees live cases and decides nothing; its disagreements with the people are the instrument.
- surprise rate
- The rate at which live operation produces cases the design did not anticipate; its decline, not accuracy, marks convergence.
- three registers
- The stated, the enacted, and the revealed; their disagreement is the information.
- work-as-done
- What people actually do, as against the work-as-imagined of documentation. Senior.