Your model is not
the whole system.

Four engineering seams

Choose the transition your team cannot afford to guess about.

1. Memory or retrieval → next-agent context

Bind: subject or tenant, record identities, source revision, query/filter parameters, embedding or retrieval configuration, and the exact returned context.

Refuse: stale facts, wrong-subject memory, cross-collection results, missing source identity, changed selection, or an incomplete context family.

2. Dataset or evaluation → release decision

Bind: dataset items, prompt or agent revision, scorer code/configuration, completed run identity, required scores, thresholds, and the declared consumer decision.

Refuse: partial runs, missing scores, mixed revisions, foreign datapoints, mutable result substitution, or a release conclusion detached from its evaluated bytes.

3. Tool or model result → external effect

Bind: request identity, tool/schema version, arguments, result, attempt history, known effect identity, and explicit action authority.

Refuse: schema-valid but unowned calls, ambiguous retries, unknown outcomes, duplicate effects, conflicting receipts, or a review record presented as execution permission.

Runnable reference: the checked-in agent action admission demo commits a typed synthetic request, exact pre-state and simulator contract before a deterministic local transition. It grants no real tool or effect authority.

4. Workflow or sandbox state → later continuation

Bind: workflow revision, step/attempt identity, input and output artifacts, persisted state or volume generation, terminal status, and the next eligible step.

Refuse: stale checkpoints, foreign runs, last-writer ambiguity, incomplete artifact publication, replay conflict, or continuation after an unproven terminal state.

A useful way to work

Make one transition small enough to test and understand.

Boundary contract

Exact source, artifact, consumer, costly false promotion, required evidence, authority, and known exclusions.

Bounded adapter

One small implementation that admits the agreed valid path and returns named fail-closed decisions for every rejected path.

Hostile proof

Valid fixture plus missing, malformed, stale, substituted, conflicting, duplicate, replay, and uncertain-outcome cases that apply to the chosen seam.

Decision receipt

A machine-readable projection of what was accepted or refused and why, without inventing delivery, deployment, effect, or business authority.

Engineering handoff

Reproduction command, known limits, one review round, and the smallest credible next hardening step—if the proof justifies one.

Keep the boundary small

Start with the part that can cause a real mistake.

Keep the orchestration, observability, or evaluation tools your team already uses. This work hardens one exact transition in your codebase: the source, target, costly false promotion, and proof that the rejected paths stop there.

A local test can show whether a particular mistake is refused. It cannot, by itself, prove that an entire production system is safe.

For a real system

First understand the source, destination and failure.

• One sanitized source artifact or interface description.
• The target system or decision it can change.
• One valid example and the expected result.
• One costly false promotion the adapter must stop.
• A local, CI, or sanitized test environment—or an explicit discovery-only boundary if none exists yet.

Acceptance

“Done” is executable, not persuasive.

valid fixture       → admitted with named evidence
hostile fixtures    → held with named reasons
replay              → idempotent or conflicting, never ambiguous
external authority  → false unless separately granted
proof command       → green from a clean checkout

The public repository demonstrates this pattern with synthetic fixtures. A real integration needs its own inputs, owners, acceptance checks and permissions. These examples do not prove production safety, customer results or external effects.

Continue the conversation

One concrete example is enough to begin.