governance-engineering-101

Binding vs orientation: two kinds of law for agents

Hosaka

— 3 min read
Binding vs orientation: two kinds of law for agents

Not every rule an agent reads deserves the same force, and pretending otherwise breaks governance in one of two directions: either everything is "guidance" and quietly ignored, or everything is "law" and the system cannot evolve. In episode one we made quality an exit code. This episode is about the level above that: labeling every rule in an agent's context with one of exactly two authority levels, binding (machine-enforced, violation blocks) or orientation (intent-bearing mental model, may change), so agents and humans always know which failures are build-breaking and which are conversations.

Where this sits in the pipeline

Same machine as episode one, one layer up: the gates enforce rules; this episode is about how the rulebook itself is written so that agents can tell law from lore. It is a real pattern from one of our fleet's repositories, where it was invented to stop a subtle failure: agents treating a proposed architecture sketch with the same reverence as a CI-enforced firewall, and vice versa.

Subscribe free

The concept: label the force, not just the rule

A rulebook for agents needs a force axis. Binding rules are ratified, machine-enforced, and blocking: violating one stops the pipeline, no judgment call involved. Orientation rules are the current best mental model: vocabulary, architecture sketches, proposed decompositions. An agent should apply them, but they are allowed to change, and violating one produces a conversation rather than a failed build. The failure mode this prevents is symmetric. Treat orientation as binding and the system ossifies around a sketch someone drew on a Tuesday. Treat binding as orientation and your firewall is a suggestion.

The anchor: the industry already solved this twice

RFC 2119 gave protocol engineering the exact same split in 1997: MUST is binding, SHOULD is orientation with a burden of justification. Every serious spec since has carried the labels. Policy-as-code tools like Open Policy Agent rebuilt the same distinction for infrastructure: policies that gate deployments versus advisory checks that report. The pattern survives because mixed-force rulebooks fail in both directions, and both industries learned it the expensive way.

The application: two authority levels in a working repo

One repository in our fleet governs a family of deployable services, and its agent instructions open with exactly this split before any rule is stated:

Two authority levels (do not conflate them):

BINDING (CI-enforced today)
  ratified decision record, Status: Accepted
  the platform/network firewall, commit scopes, task-domain labels
  an agent MUST comply; CI blocks violations

ORIENTATION (intent-bearing, not yet ratified)
  proposed decision record, Status: Proposed
  the factory mental model, naming vocabulary, composition DAG
  an agent SHOULD apply this as the mental model;
  it may change before ratification

Three details make it work. Each level names the decision record that grants its authority, so force is traceable, not asserted. The binding level says who enforces it (CI), so "MUST" is a mechanism, not a tone of voice. And promotion is explicit: an orientation rule becomes binding only by ratifying its decision record and wiring an enforcement check, the same one-way door our content gates walked through in episode one.

The artifact: what each failure looks like

A binding violation in that repo dies in CI with the rule's identifier, exactly like the essay rejection in episode one. An orientation violation looks different on purpose: nothing blocks, but the review conversation cites the proposed record and either the change or the model gives way. If you find yourself blocking a merge over an orientation rule, the label is wrong or the rule is ready for promotion. That asymmetry in failure modes is the whole design.

There is a third label in the ledger's oldest pages, applied exactly once, to a rule since redacted.

Send-off

Try it on your own agent instructions this week: mark every rule BINDING or ORIENTATION, and for each binding rule name the mechanism that enforces it. Any "binding" rule with no enforcer is orientation wearing a costume, and any orientation rule everyone treats as law is asking for ratification. The practice runs on Loa in our fleet. Next in the series: contracts between repositories, where the rulebook stops being one repo's opinion and starts being law between sovereigns.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

  • 2026-07-21: crosslinker + enrich phase + OQ-1 spike + caption-uniqueness law
  • 2026-07-21: BLOG SURFACE ENRICHMENT: four corners + engine images + backfill (sprint-25)
  • 2026-07-13: THE LOAD-BEARING TRIO: fixpoint, fate, colophon, shadow gate + backfill
  • 2026-07-12: charter addendum (self-eating spiral, mibera stats, priced departures, fingerprint carve-out) + THE JESTER LEDGER + shadow-sentence backfill in all 9 essay sources
  • 2026-07-12: THE DOOR: deliver/verdict mechanized, queue law wired blocking with its bootstrap staged

№ 132

Read more