Skip to main content
Behavioral Observatory labels count as durable evidence only after an authorized save succeeds and the saved value can be read back. The source contract reviewed on 2026-08-12 keeps one label per reviewer per run item and assumes the reviewer is the signed-in owner/user for this privileged surface.

​
Status

  • Durable label schema and save adapter: implemented in tracked source.
  • Saved-label reload: implemented when the durable service is available.
  • Reviewer equals signed-in owner/user: current source assumption.
  • Evaluator reviewing an owner run: deferred pending an explicit authorization change.
“Current” on this page means the source contract reviewed on 2026-08-12. It does not assert that the schema or authorization rules were re-proven against live Supabase. For dated platform truth and evidence limits, see Current System State. A tracked schema change is source evidence only. Verify an authorized write and readback before claiming that persisted labels are available in a live environment.

​
Durable evidence boundary

Behavioral labels belong to a dedicated durable evidence domain, separate from Review Queue scoring. The durable record binds:
  • the evaluated run item
  • the run owner
  • the reviewer who made the judgment
  • the structured label and optional notes
  • save state and audit timestamps
The important product distinction is:
Do not collapse those two meanings.

​
Label values

Current intent values:
Current guest_affect values:
Current response_strategy values:
Current humanness range:
Current status values:

​
One-label rule

There is one label per reviewer per run item. The durable layer enforces that product rule without exposing its database key composition here. Saving again updates the same reviewer’s label for that run item instead of creating a second label.

​
Authorization boundary

The durable service evaluates the authenticated identity and the ownership relationships for the run, item, and label. A visible route or enabled Save control is not proof that the write is authorized. The source contract is intentionally narrow: it permits the privileged signed-in owner/user workflow and fails closed outside that relationship. The current narrow contract assumes:
That means current policies are not yet the broader evaluator-reviewing-owner-run workflow.

​
Current limitation

The source persistence model supports owner/user-owned run labeling on the privileged Behavioral Observatory surface. It is not yet sufficient for a future workflow where:
That future workflow requires policy and product changes so the reviewer can read/write the correct row without pretending to own the run. Do not claim this is already implemented.

​
Saved / unsaved / error states

The UI should preserve these truth states:
  • derived: suggested from existing run/review context, not saved
  • unsaved: reviewer changed values but did not save
  • saving: save is in progress
  • saved: Supabase confirmed the label
  • error: save/load failed
Only saved should be treated as persisted Behavioral Observatory label data.

​
Verification contract

Source, deployment, and live data are separate claims. A release is not enough by itself. To verify live persistence, use an approved account and confirm that:
  1. the write is accepted for the intended reviewer and run item;
  2. the UI reports saved only after the durable service confirms it;
  3. the same value reloads after refresh;
  4. a second save updates the same reviewer’s label instead of creating a duplicate; and
  5. a rejected or failed write is never counted as persisted evidence.
No authenticated production write or count was performed during the 2026-08-12 documentation review.

​
Future support

Future evaluator workflows may require:
  • owner/admin assignment records
  • evaluator-to-owner review grants
  • durable authorization rules that allow assigned reviewers to label owner runs
  • clearer reviewer/owner separation in UI copy
  • audit views for who saved which Behavioral Observatory label
Treat these as future/deferred until implemented and verified.