June 2025
Deterministic by Design
Architecture patterns for AI-assisted systems with hard boundaries.
Deterministic does not mean no AI. It means the parts that must be predictable are predictable. The model can suggest a classification. Code decides what happens next.
Separate inference from execution
Inference produces a candidate: a label, a extracted field, a draft paragraph. Execution applies rules: route to queue B, reject if confidence below threshold, require second signature if value exceeds limit.
Never let the model call tools in a loop without a hard step limit and a schema for every output. Wrap calls in functions that validate JSON before anything touches a database.
Make state explicit
Workflows live in tables with statuses, not in chat history. pending, in_review, approved, rejected. Every transition is a row. Every row has who and when.
If your system cannot answer how many items are stuck in review right now, state is hidden somewhere it should not be.
Version everything that drifts
Prompts, model IDs, extraction schemas, business rules. Tag releases. Diff them in CI. When audit asks what the system did in Q2, you check out the tag from Q2.
Design for failure
Models timeout. APIs rate-limit. PDFs are scanned upside down. Retries with backoff, dead-letter queues, and human escalation paths are not optional in regulated work. They are the design.