Design the production boundary

Model the system that must remain true

Begin with domain identities, states, transitions, and invariants. A model response may propose a classification or action, but trusted software decides whether it is structurally valid, current, authorized, and safe to apply. Keep workflow state, evidence maturity, proposal state, human disposition, currency, and readiness orthogonal.

For complex systems, use a typed dependency graph to trace source evidence, decisions, artifacts, and downstream effects. The graph is a derived navigation and change-intelligence layer, not an authorization system. Every edge needs provenance, currentness, and a typed relationship so selective propagation can be tested.

Draw trust and effect boundaries

Mark where untrusted user input, retrieved content, model output, tools, credentials, and systems of record cross boundaries. Recheck caller identity, tenant, scope, policy revision, approval freshness, and capability version at the effect boundary. A prompt, tool description, or agent plan cannot grant authority.

Specify failure behavior for timeouts, malformed output, duplicate requests, partial effects, stale evidence, concurrent changes, unavailable dependencies, and failed readback. Safe design includes interruption and recovery paths, not just a happy-path sequence diagram.

Bind context to the decision route. For every source, record purpose, source authority, label or expected-output authority, preparation lineage, version and freshness, restricted fields, retention, quality checks, and behavior when required context is missing or contested. Derived context may support a decision; it does not silently become a system of record or permission source.

Bind the smallest useful slice

Describe components, contracts, telemetry, and release tests for one vertical slice. Avoid a framework-first topology. The design is complete when a reviewer can trace evidence to decision, authorization, effect, verification, and rollback for the slice.