The book becomes useful when its ideas become instruments.

1. State: What the system currently is — the values that determine what is allowed and what comes next.
2. Memory: What the system carries forward across moments: history, context, identity, accumulated user truth, and what it chooses to forget.
3. Permissions: Who can do what, when, and on whose behalf: the quiet rules that shape what is even possible to attempt.
4. Timing: When the system acts, waits, suggests, or stays silent: the rhythm of behavior.
5. Confidence: How certain the system is about what it knows or proposes, and how that uncertainty changes what should happen next.
6. Autonomy: How much the system may do before it checks back: observe, prepare, act and show, or act and report, set per function and per class of action rather than once for the product.
7. Orchestration: How separate parts coordinate: the choreography between user, machine, interface, data, and adjacent systems.
8. Recovery: What happens when something goes wrong: the structure of undo, repair, retry, restore, and recourse.
9. Visibility: What the system makes legible about its own behavior, state, memory, assumptions, and reasoning.

1. Intent (Person): The user arrives with a goal, often only partially specified; the product treats it as intention, not always as complete instruction.
2. Interpretation (System): The system forms a working understanding from the request, context, defaults, history, and available data.
3. Suggestion (System): The system proposes an output, action, classification, draft, or next step, framed according to confidence and stakes.
4. Review (Person): The user evaluates whether the suggestion fits the goal, context, and consequences.
5. Delegation (Person): The user hands the system bounded work to carry out: what it may touch, how far it may go, and when it must stop and ask. Optional; when it happens, the grant is as legible as the suggestion.
6. Report back (System): The system returns an account of what it did, skipped, assumed, and could not undo; for delegated work, the report is the review surface.
7. Correction (Person): The user edits, rejects, redirects, accepts, or clarifies what the system produced.
8. Adaptation (System): The system changes what it does next based on the correction; the change may be temporary, durable, or global.

1. Notice: What does the system observe, and what should it ignore?
2. Infer: What meaning does the system derive, and how confident is it?
3. Act: What can the system do without explicit instruction?
4. Ask: Where does the system need consent, confirmation, or human judgment?
5. Reveal: What must stay visible for trust to hold?
6. Reverse: How does the user recover from a wrong action?
7. Back off: When should the system stop helping?

1. Legibility: The system makes its actions, reasoning, state, and assumptions visible enough to be understood, questioned, and corrected by the people it acts on behalf of.
2. Reversibility: Reversible actions can be undone cheaply. Irreversible external actions require an explicit compensating path and named owner.
3. Controllability: The user can constrain what the system is allowed to do, both in advance through configuration and in the moment through override.
4. Recoverability: When something breaks, there is a clear path back to a known good state without losing the context the user needs to continue.
5. Consistency: The same input, in the same context, produces the same behavior — or the difference is named, not hidden.
6. Restraint: The system declines to act when evidence, measured reliability, authorization, consequence, or recovery does not support action.

Builds from the bottom up

1. Trigger (System): Where does the work actually begin, before the product is opened?
2. Context (Person): What does the user already know, and what should the system know on their behalf?
3. Decision points (Person): Where does the user make a real choice, and where is the product asking for a choice it should learn, default, or prepare?
4. Handoffs (System): Where does work move between people, tools, systems, or surfaces?
5. Repetition (System): What happens often enough that the system should notice the pattern?
6. Bottlenecks (System): Where does the work wait, and is the waiting intentional or accidental?
7. System assistance (System): Which steps could the system safely prepare, suggest, classify, summarize, automate, or route?
8. Human control (Person): Which decisions must remain visibly and meaningfully in human hands?

1. Real capability: The actual skill, judgment, and practice required to do the work you are claiming.
2. Visible proof: Artifacts, decisions, prototypes, writing, or case studies that make the capability believable.
3. Clear language: A precise way to describe the role, value, and standard without borrowing empty seniority language.

Remove one leg and the position collapses.

1. Standards: What quality bar, evaluation practice, and regression standard do you hold even when nobody hands them to you?
2. Point of view: What do you believe good software behavior should make possible?
3. Taste: What do you choose, refuse, simplify, or slow down because it improves the work?
4. Responsibility: Which consequences and evaluation failures do you accept responsibility for in the product you helped shape?
5. Consistency: Where do your standards show up repeatedly enough to become recognizable?
6. Reflection: How do you inspect your own decisions and make your practice sharper over time?

1. Surface: What the user sees and touches: screens, layout, hierarchy, components, copy, interaction states, affordances, motion, and visual clarity.
2. Flow: How the user moves through the work: the sequence between actions, screens, decisions, states, and handoffs.
3. Logic: The deterministic spine beneath the experience: rules, validations, conditions, calculations, constraints, dependencies, and edge cases.
4. Behavior: What the system does over time, on whose authority, with what restraint: what it notices, infers, suggests, automates, delays, asks, hides, reveals, remembers, and reverses.
5. Strategy: What is worth building at all, and why now: which problem the product takes, which it refuses, who it serves, and what future it makes possible.

1. Assumption: What behavioral belief is the prototype trying to prove or disprove?
2. Trigger: What starts the behavior, and who or what initiates it?
3. System response: What does the system do in response, over time or immediately?
4. Visibility: What does the user need to see about state, reasoning, confidence, or consequence?
5. User control: Where can the user steer, pause, override, or refuse the behavior?
6. Failure case: Which must-act and must-not-act cases expose what happens when the system is wrong, late, uncertain, or incomplete?
7. Recovery path: How does the user repair the situation without losing trust or context?

1. Trigger: Which exact event or rule makes this behavior eligible to run, and which conditions must prevent it?
2. Inputs: Which evidence, signals, and context does the behavior use, and how are origin, independence, conflict, and freshness checked?
3. Confidence: What measured task reliability supports this use, and how was any threshold calibrated on representative cases rather than model self-report?
4. System action: What interpretive work does the system do, and what does it propose, prepare, execute, withhold, or refuse?
5. User control: What is the system explicitly authorized to do, and where can the user constrain, pause, override, decline, or revoke that authority?
6. Visibility: What evidence, state, consequence, and recovery or compensating path must remain visible when the action lands?
7. Correction: How does the user correct a wrong result, repair affected state, and control whether that correction becomes memory?
8. Backoff: When and how does the system stop acting — temporarily, durably, or globally — when it should not?
9. Autonomy level: Delegation section. Which level does each class of action get — observe, prepare, act and show, or act and report — and what evidence would widen or narrow it?
10. Intent preview: Delegation section. What does the person see before the act, or before they leave: the action, the scope, the grant it runs under, the consequence class, and what the system will not do?

1. Clarity: Does this make the work easier to understand or decide?
2. Speed: Does this remove meaningful delay without erasing judgment?
3. Confidence: Does this help people trust what they are doing next?
4. Quality: Does this raise the standard of the outcome, not just the pace?
5. Coordination: Does this make handoffs, roles, or dependencies cleaner?
6. Decision-making: Does this improve the choices people can make with the product?

1. Does this deserve automation?: Decide whether the system should take over the work, prepare it, or leave it in human hands.
2. Does this deserve friction?: Name where slowing the user down improves judgment, trust, or quality.
3. Does this need visibility?: Decide what must be made legible instead of hidden behind convenience.
4. Does this need restraint?: Identify where the product should refuse, pause, ask, or back off.
5. Does this simplify the user's work?: Separate true simplification from merely moving complexity somewhere else.
6. Should this exist at all?: Ask whether the feature creates enough value to justify its behavioral surface.

1. Inputs: What information, events, or user actions does the system depend on?
2. Transformations: What happens to those inputs before the user sees a result?
3. Outputs: What does the system return, show, store, trigger, or change?
4. Constraints: What limits shape the system: permissions, latency, data, cost, policy, or reliability?
5. Risks: Where could the system produce harm, confusion, false confidence, or broken trust?
6. Feedback loops: How does the system learn, update, or respond to user correction?
7. Failure modes: How does the experience behave when the system is wrong, slow, missing data, or unavailable?
8. Evaluation: Which representative cases, must-act and must-not-act constraints, outcome checks, and final-state checks establish acceptable behavior?

1. Reframing a problem: Show that you can change the level at which a product question is understood.
2. Redesigning a workflow: Show that you can reshape work, not just improve a screen.
3. Modeling system behavior: Show what the system should notice, decide, remember, reveal, and recover from.
4. Showing tradeoffs: Show the judgment behind what you chose, refused, simplified, or delayed.
5. Expressing a point of view: Show standards, taste, and direction that go beyond execution.
6. Building a concept with real logic: Show enough working behavior, evaluated outcomes, critical-constraint checks, and regression evidence that the idea can be tested and discussed.

1. What am I hired to do?: Name the official shape of your role: what is assigned, rewarded, and expected.
2. What am I capable of seeing?: Name the product questions you notice, even when they are not formally yours.
3. What do I keep wanting to influence?: Name the decisions you cannot stop caring about and the direction your work is pulling you.
4. What am I not invited to touch yet?: Name where you have opinions but no authority, or where you are brought in too late.
5. Where do I feel most alive in the work?: Name the moments where your attention sharpens, then test whether the pattern survives changes in workload, environment, and responsibility.