V01 / Illustrative framework
Software build: brief to estimate
A brief is ready for estimation when the user problem, constraints, exclusions, and acceptance checks are explicit.
The visual library
Systems you can see.
Original diagrams for the decisions behind software: scope, architecture, delivery, data, and the people who keep it working. Each graphic links to the explanation, assumptions, and practical example behind it.
52 graphics · SVG originals · PNG downloads
Decisions and engineering practice
V02 / Illustrative framework
Draw the boundary before the estimate
An illustrative scope for an appointment-booking release; this is a planning example, not a client result.
V03 / Illustrative framework
A proposed first-month cadence
An illustrative 30-day leadership engagement: learn the system, review choices, agree priorities, and reassess.
V04 / Illustrative framework
Make decision ownership explicit
A suggested decision pattern, to be agreed with the actual team rather than imposed as a universal org chart.
V05 / Illustrative framework
The build-buy-integrate decision
Build the differentiating core, buy a suitable commodity, or integrate with an existing system; every path needs a maintenance owner.
V06 / Illustrative framework
The whole ownership picture
Ownership includes operation and an exit path, whether the capability is built, bought, or integrated.
V07 / Illustrative framework
Agent authority and trust boundaries
Keep untrusted inputs, isolated implementation, human review, and credentialed release on separate authority boundaries.
V08 / Illustrative framework
The escalation contract
Allow bounded reversible work, review external effects, and stop when authority or secret handling is unclear.
V09 / Illustrative framework
From requirement to evidence
Start with an independent requirement, then gather unit, integration, browser, and review evidence for different failure boundaries.
V10 / Illustrative framework
What a passing test does not prove
A local rule, shared-state invariant, and visible user journey need different tests; none alone proves production delivery.
V11 / Based on the documented workflow
One request identity, several attempts
A stable key lets an unchanged retry find the same saved record. Changed content needs a new request identity.
V12 / Based on the documented workflow
Saved and notified are separate facts
The durable inquiry receipt survives a notification failure. An unknown delivery result needs investigation rather than a blind resend.
V13 / Illustrative framework
Reconcile before cutover
Reconcile stable identities and meaningful fields, capture late writes, and compare the final delta before switching traffic.
V14 / Illustrative framework
The rollback boundary
After destination writes or external effects, recovery requires reconciliation as well as a deployment decision.
V15 / Illustrative framework
From click to trusted event
A versioned event moves through validation, consent checks, delivery, and deduplication before becoming a durable consumer result.
V16 / Illustrative framework
The event contract card
An event contract names identity, meaning, version, time, permission, and ownership; the values shown are synthetic.
V17 / Illustrative framework
Generation is one step
Generation produces a candidate. Checks and human review decide whether that exact revision is ready to publish.
V18 / Illustrative framework
The review rubric
Review structure, evidentiary support, and usefulness separately; return unsupported or ambiguous output for revision.
V19 / Illustrative framework
Who owns the system after launch?
An incoming owner needs a runnable environment, integration boundaries, role-based access, operational signals, and a recovery rehearsal.
V20 / Illustrative framework
The handoff acceptance checklist
Accept a handoff by demonstrating how to run, change, diagnose, recover, and eventually retire the system.
V21 / Illustrative framework
Inspect evidence across the whole product
Use this as a conversation guide. A public work sample does not prove every capability or reveal private work.
V22 / Illustrative framework
Move from the demo to the decision
A proposed hiring conversation connects an inspectable artifact to its constraints, alternatives, and ownership.
V23 / Illustrative framework
Where a page spends its time
Schematic stages without a timing scale; measure the actual journey before choosing an optimization.
V24 / Illustrative framework
The performance decision loop
Choose a user journey, measure its limiting stage, change one suspected cause, and retain or revert the change using comparable evidence.
V41 / Based on the documented workflow
A feature becomes a reviewable stack
A decomposition example from the article. Later changes depend on earlier contracts; reverting a foundation may require reverting its dependents.
V42 / Based on the documented workflow
The engineering operating loop
A summary of the article’s described workflow, with human judgment retained for priorities, reviews, and consequential decisions.
V43 / Illustrative framework
Parallel work without shared working trees
Isolated worktrees still need independent review, shared-contract reconciliation, and a combined verification pass before integration.
V44 / Illustrative framework
A context hierarchy for coding agents
Keep stable preferences, repository rules, current task context, and detailed references in distinct instruction layers.
V45 / Illustrative framework
From inquiry to accepted proposal
Historical reference architecture; the article describes the earlier proposal system.
V46 / Illustrative framework
What confirms a checkout?
A browser redirect supports navigation; verified provider notifications and durable reconciliation establish authoritative payment state.
V47 / Illustrative framework
A staged commerce cutover
A staged commerce cutover rehearses mappings and invariants, accounts for late writes, and observes orders after the traffic switch.
V48 / Illustrative framework
The evidence ladder before building
Distinguish a favorable opinion from observed friction, a concrete commitment, and actual use; the ladder contains no conversion rates.
V49 / Illustrative framework
The variables behind a test result
Conceptual dependency map, not measured causal effects.
V50 / Illustrative framework
A question through the data stack
Authorize data access and resolve governed metrics before querying; return checked results with provenance and uncertainty.
Architecture and field guides
V25 / Illustrative framework
A compatible API transition
Keep old and new clients working during an explicit transition; confirm adoption before removing the earlier contract.
V26 / Illustrative framework
The compatibility checklist
An additive field can break a strict reader, while changed defaults or error semantics can break behavior without changing shape.
V27 / Illustrative framework
Control and execution planes
The control plane owns intent, limits, and reconciliation; the execution plane performs scoped work and records its outcome.
V28 / Illustrative framework
When feedback becomes a decision
A signal becomes an operational decision through evidence, an accountable owner, an approved action, and outcome verification.
V29 / Illustrative framework
The first-change path
Onboarding is exercised through one reversible change, from access and setup to review, release, and a rollback explanation.
V30 / Illustrative framework
The ownership map
The teammate, reviewer, and access or incident owner share different responsibilities for making the first useful change possible.
V31 / Illustrative framework
One useful slice through the stack
A useful booking slice connects user action to authorization, atomic reservation, durable identity, and visible conflict or confirmation.
V32 / Illustrative framework
The release scope map
Keep the complete booking outcome in the release; defer convenience and explicitly exclude unrelated product scope.
V33 / Illustrative framework
The lineage of an answer
A trustworthy answer traces its metric definition back through transformations, deduplication, provenance, and the original event contract.
V34 / Synthetic example
Why two dashboards disagree
Synthetic event counts illustrate different metric definitions; these are not site analytics.
V35 / Illustrative framework
The hypothesis tree
Use the whitespace counterexample to distinguish a browser hypothesis from a server truthiness defect, then replay valid and invalid inputs.
V36 / Reproducible example
The debugging evidence board
Reproducible JavaScript validation example; see the adjacent experiment and its limits.
V37 / Illustrative framework
Contain, inspect, restore
Contain unsafe writes before choosing a repair; verify recovered state and a user journey before resuming gradually.
V38 / Illustrative framework
The recovery decision ladder
Revert code, restore a validated backup, or reconcile divergent histories according to the affected state and later writes.
V39 / Illustrative framework
The order lifecycle
Payment confirmation, fulfillment, delivery exceptions, and refunds have distinct authorities that must be reconciled with the order.
V40 / Illustrative framework
Payment events across system boundaries
Verify signed events, commit identity and state durably, then fulfill through a retry-safe worker keyed by order identity.
Product and delivery
V51 / Based on the documented workflow
Inside the Lively Icons demonstration
The portfolio demo combines static icon artwork, React selection state, and optional motion; reduced-motion preferences keep the static foundation useful.
V52 / Based on the documented workflow
The review boundary in product imagery
A summary of the documented workflow: inputs and generation do not replace human approval before publication.
Put the model to work.
A diagram starts the conversation. The useful part is connecting it to your system and its constraints.