You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wire POTESTAS into studium's existing analysis spine. Do not build a second one.
Event types
Add to studium/analysis/events-schema.yaml:
mechanism_observed — {mechanism: <registry id>, channel: <medium class>}. A named mechanism was recognized in the wild. This is the program's core signal: it measures recognition, which is the actual trained skill.
Also add disclosure and negotiation to the rubric enum for the rubric_score event.
Posture — inherited, non-negotiable
From the schema's own header: append-only, local-first, non-PII.actor is self. Never a name, email, handle, or message body — only the structured fields above. Community-scale collection stays consent-gated.
mechanism_observed records the mechanism id, never who did it. That constraint is what keeps the event stream a record of a skill developing rather than a dossier on a person, and it is the structural mitigation for this program's named failure mode.
Ledger
POTESTAS entries use the existingstudium/ledger/studium-YYYY-MM-DD.md per-day format. No new ledger, no new cadence, no automation. Self-scored, slow.
Why decision_deferred matters most
Every other event in this program records something being noticed. That one records something being done differently. It is the only event whose count going up means the training worked rather than that the observer got more sensitive.
Done
The three event types and both rubric names are in events-schema.yaml, the ledger format carries POTESTAS entries, and no event field can hold identifying free text.
Phase: #2084 · Program: #2077
Wire POTESTAS into studium's existing analysis spine. Do not build a second one.
Event types
Add to
studium/analysis/events-schema.yaml:mechanism_observed—{mechanism: <registry id>, channel: <medium class>}. A named mechanism was recognized in the wild. This is the program's core signal: it measures recognition, which is the actual trained skill.drill_run—{family: <mechanism family>, named_correctly: bool}. Inoculation practice.decision_deferred—{class: financial|commitment|scope}. The financial-decision protocol (Φ4 POTESTAS — DEPLOYMENT (prestige route): the two named training failures #2082 → 4.2) held: a decision was moved off a synchronous channel. The one event that records a protocol working rather than a failure being observed.Also add
disclosureandnegotiationto therubricenum for therubric_scoreevent.Posture — inherited, non-negotiable
From the schema's own header: append-only, local-first, non-PII.
actorisself. Never a name, email, handle, or message body — only the structured fields above. Community-scale collection stays consent-gated.mechanism_observedrecords the mechanism id, never who did it. That constraint is what keeps the event stream a record of a skill developing rather than a dossier on a person, and it is the structural mitigation for this program's named failure mode.Ledger
POTESTAS entries use the existing
studium/ledger/studium-YYYY-MM-DD.mdper-day format. No new ledger, no new cadence, no automation. Self-scored, slow.Why
decision_deferredmatters mostEvery other event in this program records something being noticed. That one records something being done differently. It is the only event whose count going up means the training worked rather than that the observer got more sensitive.
Done
The three event types and both rubric names are in
events-schema.yaml, the ledger format carries POTESTAS entries, and no event field can hold identifying free text.