02 / the working method

clear decisions. working systems.

The work should get easier to understand as it moves forward.

Four stages connect a useful problem to software that can be operated.

inspection bay / improvenominal · illustrative

break the happy path / select a condition

the question

A rewrite is a decision. Evidence comes first.

Conceptual engineering exercise. No live system is being tested or altered.

understand the constraints.

Start with the people using the system, the outcome they need, and the conditions the work has to respect. Existing software, data access, ownership, and operational limits all belong in the conversation.

what you can inspect: A shared problem statement, constraints, and open questions.
what we need together: Your current workflow, the desired change, and what already exists.

define the shape.

Map the system and the critical paths. Make the scope, interfaces, permissions, and failure cases explicit. For AI workflows, define evaluation examples and the decisions a person must review.

what you can inspect: Architecture decisions, a sequenced scope, and acceptance criteria.
what we need together: Decisions on priorities, tradeoffs, and access to the necessary systems.

build. inspect. verify.

Implement in reviewable increments. Walk through the real workflow, test the important behavior, and inspect the result on the devices and environments that matter. Keep unresolved issues visible.

what you can inspect: Working software, verification evidence, and an issue record.
what we need together: Timely review of the product behavior and feedback from the people using it.

prepare it to operate.

A release is a transition into operation. Document deployment, access, monitoring, recovery, and ownership. Agree on the handover and any continuing engineering support before calling the work complete.

what you can inspect: Source and system documentation, runbooks, and a handover plan.
what we need together: A named system owner and decisions on release and ongoing support.

working principles

the standard is
in the details.

make tradeoffs explicit.

Every system has limits. Write down what a choice buys, what it costs, and what would change the decision.

keep people in control.

Automation needs clear permissions, review points, and a useful recovery path when the unexpected happens.

leave evidence.

Use reproducible checks and observed behavior. A passed build, a tested workflow, and a remaining limitation are different things.

the reviewable path

from observed work
to an engineering decision.

problem → workflow → review points → service → brief

01name the job
Start with the person, record, or decision that needs to move.
02trace the workflow
Find the handoffs, rules, source material, and exception paths.
03put review where it matters
Make permissions, evaluation, recovery, and operational visibility inspectable.
04choose the service
Build, useful AI, or reliability work becomes a bounded engineering question.
05write the brief
Carry the current situation and useful outcome into a reviewable local draft.

next / make it concrete

let’s define the work.

scope a project

You don’t need a polished specification.
A real problem is a useful place to start.