Notebook · My methodology
How I think about
building AI systems.
The questions I work through when translating a business into context, capabilities, and decisions an AI system can act on.
The methodology
Five questions before building.
I start with what success means. Then I ask what each role needs to know, what changes its understanding, and what evidence would justify giving a system more responsibility.
Legibility in practice
Making a function legible.
I map each function end to end. I’m looking for what each unit owns, consumes, and exposes, so that its context and responsibilities can be represented explicitly.
For me, the map comes before the architecture. It exposes the missing context, conflicting objectives, and ambiguous ownership that a model alone cannot resolve.
Make a function legible before automating it
- Owned inputsSources, permissions, and prerequisites
- Defined workSteps, tools, decisions, and exceptions
- Judgment gatesWho can approve what, with which evidence
- Usable outputsA clear contract for the next consumer
Prioritization
How I evaluate and classify.
Score every opportunity
- Business value
- Data readiness
- Risk
- Engineering effort
- Strategic importance
- Estimated ROI
A score informs a choice; it does not replace judgment.
Classify by autonomy
I treat autonomy as a decision to earn through evidence. Task risk, evaluation results, reversibility, and oversight matter more than a model’s confidence alone.
What guides my choices
Design principles.
Naming is the UX
Functions are named the way the business names work, so a manager can read the system like a table of contents.
Make the role inspectable
I describe roles through inspectable specifications: inputs, tools, standards, triggers, error paths, and escalation. The role definition should be understandable even when the model’s internals are not.
Make silence interpretable
A quiet system might be working well, or it might have stopped observing. I want monitoring that distinguishes the two.
Isolate judgment
I want routine execution to reduce the demand on attention, while uncertainty, exceptions, and consequential choices remain visible to people.
People retain control
People need to know what a system can do, why it is asking for a decision, and how to correct or stop it. Control must be practical, not merely promised.
A recursive concept engine
I treat recurring corrections as candidates for changes to instructions, tools, or workflows. Those changes need evaluation and review before becoming the new default.
A correction is a candidate, not a new rule
- ObserveCapture the error or correction with its context.
- ProposeIdentify the instruction, tool, or workflow that might change.
- EvaluateTest the change against the original failure and relevant counterexamples.
- ReviewAn owner approves the scope and records the version.
Observe the next runs; reverse or refine the change if the evidence does not hold.
The aim
More context for the decisions that need judgment.
What I’m aiming for
The direction I’m interested in is a business whose roles have clearer context, whose capabilities can respond to relevant events, and whose decisions remain accountable.
I don’t see this as a finished architecture. It is a way to reason about systems that need to be observed, maintained, and revised as the business and the models change.