iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🧱

The Determinism Series: Architectures for "Siliconizing" Decision-Making (Table of Contents)

に公開
AI
architecture
SRE
distributed
決定論
idea

Deterministic Series: An Architecture for "Siliconizing" Decision-Making (Table of Contents)

The goal of this series is simple.

Anything that can be codified into rules should be "siliconized" for decision-making.
In other words, shift from "judgments relying on human interpretation" to "judgments that can be reproduced via determinism."

By "determinism" here, I do not mean seeking "perfect timing" or "powerful magic."
What I am looking for is ordering and replayability.

  • Do not break the sequence of what comes first (ordering).
  • Be able to return to the same conclusion later using the same input, same rationale, and same procedure (replay).

Common Principles of This Series

0) First, Categorize the "Subject of Decision-Making" (RML: Reality Labels)

Whether something can be "siliconized" via determinism is actually determined by the target world (responsibility domain) even before implementation.
Therefore, this series implicitly assumes a "Reality Label" (RML).

  • RML-1 (Closed World): Not yet exposed to the outside / fail-safe (simulations, dry-runs, etc.)
  • RML-2 (Dialog World): Involves external parties / reconcile through dialogue and compensation (sagas, retries, reconcile)
  • RML-3 (History World): Immutable history / accumulating corrections, refunds, and explanations (ledger, auditing)

In short,
"Which world does this decision belong to?" By fixing this first,

  • How far you should automate,
  • Where human approval or compensation events are required,
  • Which evidence should be kept as an "immutable log"

becomes much clearer and less prone to fluctuation.

1) Decouple Proposal from Decision

Whether from an LLM or a human, a proposal is meant to be fluid, and that is fine.
What should be fixed is the entity that determines acceptance or rejection: the verifier.

  • Proposal (probabilistic): LLM/human outputs a plan
  • Verification (deterministic): Rules return ACCEPT/REJECT/DEGRADE
  • Execution (authority + audit): Pass only typed operations that have been verified

2) Make "Insufficiency" a First-Class Citizen (DEGRADE)

In practice, common failures are not about "rule violations" but rather insufficient decision-making material.
Therefore, the first thing to design is not REJECT but DEGRADE (Hold).

DEGRADE is not about "stopping" but rather a branch for stopping in a re-entrant way,
mechanically enumerating what is missing, and shaping it so it can be managed via SLOs.

3) Anchor Rationale in Logs (Make It a Replayable Event)

"Plausible-sounding explanations" are not auditable evidence.
What must be fixed are the input schema, policy/version, reason code, evidence ID, and the authority of the ordering.

Table of Contents (Recommended Reading Order)

4 Reading from top to bottom connects naturally from "Agents → Operations → Distributed Infrastructure."

1. The Real Reason Why AI Agents "Appear" to Work (Series Introduction)

The reason agents work in the software domain is not the cleverness of the LLM, but the deterministic guardrails (verifiers).

2. Do Not Let LLMs "Execute": Safe Business Agent Implementation using Typed Actions + Verifiers

Do not execute free-text. A minimal design for crash-proof business agents using Typed Actions + Verifiers.

3. An "Ole-Ole" (Homegrown) Design Pattern to Make Agents "Business-Ready" by Designing for DEGRADE (Hold)

When you become able to handle "insufficiency," the hell of field interpretation vanishes, and operations settle into a re-entrant state.

4. Instead of Nurturing Prompts, Nurture Verifiers: Running Operations with 10 Golden Cases

What should be fixed is not the "LLM output," but the verifier's output (verdict/reason/missing/normalized_plan). An operational theory that includes "how to nurture" via CI.

Domain Application (Bringing Determinism into "Business")

5. A "Deterministic" Design Example for Protecting Billing SaaS: API Contracts x DB Boundaries x Execution Patterns to Crush Double Billing

Shifting critical domains, where "breakage is fatal," toward a "replayable design" using ordering, idempotency, and auditing.

6. Making A/B Testing an "Operation": Goal Surface (Multi-objective + Constraints) x Deterministic Logs x Safe Automation

Turning experiments from a "one-off analysis" into an "operation." Connecting the "goal surface" of multi-objectives and constraints with DEGRADE/Watermark/Log pinning.

Infrastructure (Protecting Ordering and Replayability)

7. Deterministic Time: Architectural Design for Preserving "Ordering" and "Replayability" in Distributed Systems

Even without TrueTime, you can create an "authority of ordering" using seq / watermark / HLC. Furthermore, covering Late Data / trace closure / Dual Write (outbox, event sourcing) to ensure replayability remains intact.

Series "Checklist" (Return here when stuck)

  • If the discussion doesn't align: Is the "Which world?" (RML-1/2/3) context shared?
  • If judgments are shaky: Is proposal decoupled from verification?
  • If stuck due to insufficiency: Is DEGRADE and missing a first-class citizen?
  • If it turns into a meeting: Is the reason code typed?
  • If you cannot explain it later: Are input, policy, snapshot, and ordering anchored in the logs?
  • If it breaks during long-running processes: Is it a state machine + re-entrant? (Squash Dual Writes using outbox/event sourcing)
  • If ordering collapses in distributed environments: Which of seq / watermark / HLC are you using as the authority?

This "Deterministic Series" is a collection of parts for verification, audit trails, and operations to siliconize decision-making, but in practice, you first need to "categorize the subject of decision-making."

  • RML-1: Nurturing verifiers in a room (safe to fail)
  • RML-2: Making it "re-entrant" through dialogue and compensation (DEGRADE/ActionHint/retries)
  • RML-3: Leaving it as history and maintaining consistency through compensation events (ledger/auditing/explanation)

Once you agree on "which world we are talking about," it becomes much easier to see where parts like deterministic logs, DEGRADE, watermark, and outbox are needed.

This series is not about "doing everything perfectly," but rather a collection of parts for siliconizing decision-making starting from the most fragile areas.
It is best to start with a "minimal verifier" and "minimal log anchoring," then grow them using SLOs and reason codes.

The ultimate goal of this architecture is to build a system that makes decisions autonomously while evolving by incorporating obstacles as learning material.

If the system stops due to unknown phenomena or unexpected deficiencies, it is recorded in the deterministic log; in most cases, it is designed to lead to decisions on what to do next while minimizing investigation costs.

If the decision-making process can be codified into rules, it can be updated in the domain compiler and golden cases, allowing it to be processed automatically from the next time onward.

And as written in the golden case article, if you incorporate LLM-driven proposals for updates, you have completed an architecture where the system as a whole autonomously evolves every time it fails while making decisions.

Of course, pushing full automation this far is not easy.
However, the burden can be managed by breaking it down through SLOs, reason codes, and phased implementation.

Initially, just "verifiers + log anchoring" is highly effective.
When you want to do more, you can add domain compilers, golden case updates, and proposal generation (LLM) in sequence.

Discussion