Skip to main content
Behavioral Observatory labels persist through public.eval_behavioral_labels. The current narrow contract stores one label per reviewer per run item and assumes the reviewer is the signed-in owner/user for this privileged label surface.

​
Status

Do not treat a helper SQL file as proof that the migration was applied to live Supabase.

​
Table

Behavioral Observatory labels are stored in:
Purpose:

​
Key fields

The table stores:
The important product distinction:
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 current uniqueness rule is:
Saving again updates the same reviewer’s label for that run item instead of creating a second label.

​
RLS assumptions

Current RLS uses the Clerk JWT subject:
The current policies require the signed-in user to match:
This is intentionally narrow. The current narrow contract assumes:
That means current policies are not yet the broader evaluator-reviewing-owner-run workflow.

​
Current limitation

The current persistence model is good for 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.

​
SQL workflow

Canonical migrations live in:
Human copy/paste SQL helpers live in:
scripts/sql exists so an operator can open SQL in Finder/CotEditor and copy/paste into the Supabase SQL Editor. scripts/sql is not proof that a migration was applied. After applying SQL, run the matching verify SQL and confirm the live schema, policies, and counts.

​
Current helper files

Apply helper:
Verify helper:
Canonical migration:

​
Future support

Future evaluator workflows may require:
  • owner/admin assignment records
  • evaluator-to-owner review grants
  • RLS policies 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.