Skip to content
Software Behaviorby Joost van der Zwan
Index

Framework · Sequence · from Chapter 4

Behavior Spec

A structured template for separating exact rules, interpretive assistance, evidence, measured reliability, authority, consequences, recovery, correction, and backoff.
Read the chapter

The framework

Fig. · Behavior Spec
  1. Trigger: Which exact event or rule makes this behavior eligible to run, and which conditions must prevent it?
  2. Inputs: Which evidence, signals, and context does the behavior use, and how are origin, independence, conflict, and freshness checked?
  3. Confidence: What measured task reliability supports this use, and how was any threshold calibrated on representative cases rather than model self-report?
  4. System action: What interpretive work does the system do, and what does it propose, prepare, execute, withhold, or refuse?
  5. User control: What is the system explicitly authorized to do, and where can the user constrain, pause, override, decline, or revoke that authority?
  6. Visibility: What evidence, state, consequence, and recovery or compensating path must remain visible when the action lands?
  7. Correction: How does the user correct a wrong result, repair affected state, and control whether that correction becomes memory?
  8. Backoff: When and how does the system stop acting — temporarily, durably, or globally — when it should not?
  9. Autonomy level: Delegation section. Which level does each class of action get — observe, prepare, act and show, or act and report — and what evidence would widen or narrow it?
  10. Intent preview: Delegation section. What does the person see before the act, or before they leave: the action, the scope, the grant it runs under, the consequence class, and what the system will not do?
  1. 01

    Trigger

    Which exact event or rule makes this behavior eligible to run, and which conditions must prevent it?

  2. 02

    Inputs

    Which evidence, signals, and context does the behavior use, and how are origin, independence, conflict, and freshness checked?

  3. 03

    Confidence

    What measured task reliability supports this use, and how was any threshold calibrated on representative cases rather than model self-report?

  4. 04

    System action

    What interpretive work does the system do, and what does it propose, prepare, execute, withhold, or refuse?

  5. 05

    User control

    What is the system explicitly authorized to do, and where can the user constrain, pause, override, decline, or revoke that authority?

  6. 06

    Visibility

    What evidence, state, consequence, and recovery or compensating path must remain visible when the action lands?

  7. 07

    Correction

    How does the user correct a wrong result, repair affected state, and control whether that correction becomes memory?

  8. 08

    Backoff

    When and how does the system stop acting — temporarily, durably, or globally — when it should not?

  9. 09

    Autonomy level

    Delegation section. Which level does each class of action get — observe, prepare, act and show, or act and report — and what evidence would widen or narrow it?

  10. 10

    Intent preview

    Delegation section. What does the person see before the act, or before they leave: the action, the scope, the grant it runs under, the consequence class, and what the system will not do?

4 · Do

How to use it · Behavior spec

Fill the eight slots for one feature. When the system acts on someone's behalf, also fill the delegation section: an autonomy level for each class of action and an intent preview; the eight slots already carry the grant's authority, consequences, recovery, visibility, correction, and backoff. The output is a behavior spec the team can argue against — concrete enough that disagreement lands on a slot, not on a vibe.

5 · Save

The Product Architect · Behavior Spec

Framework · Sequence