Concept — Content Visibility States (timed release)
v3 makes timed content release a first-class concept. Every content asset moves through defined visibility states, with all transitions logged. Defaults are set by the Platform Manager; the Instructional Strategist can override per engagement.
The four visibility states
- Draft — author-only.
- Pre-engagement-visible — visible before the workshop.
- Day-of-only — visible only on the day of engagement.
- Post-engagement-released — unlocked after delivery.
All transitions are logged. IS overrides per engagement; PM owns the defaults.
Default publishing rules (PM-owned)
| Asset | Audience / timing |
|---|---|
| Pre-work | LA + Participants (pre-engagement) |
| Workshop materials | Participants, day-of only (timing-gated) |
| Slide deck | IS only (never participant-visible) |
| Post-workshop resources | Locked until IS release [D2] |
Per-engagement overrides are allowed and logged.
The locked-resources mechanism ([D1] / [D2]) — a strategic double-duty
This is more than a permission rule; it’s a return-to-platform pull:
- [D1] Pre-engagement: post-workshop resources are visible but locked/greyed, with a “releases after the workshop” label. The participant knows there’s more waiting.
- [D2] Post-delivery: the IS releases them by switching the state. Release actions are logged.
Because the resources are visible-but-locked, they create a reason for the participant to return — which is exactly what the Adjust phase and the intervention layer need to sustain repeat application.
Why state-machine, not booleans
Modeling visibility as an explicit state machine (vs. scattered boolean flags) gives:
- a single audit log of who released what, when;
- clean PM-default vs. IS-override semantics;
- a queryable “what’s locked right now” view per cohort.
See data model ideas.
Related
- Roles and goals — PM owns rules, IS releases
- Locked resources — the participant-facing experience
- Source: §6.3, §5d, user stories S3, P2 of recommendations doc