This page is for school owners. It follows what you build in a program to what
each member sees on My path, the home screen of an enrolled member, and
explains the rules that decide what opens, what is due and what counts as done.
Every program can state its transformation: where the member will be at the
end. It is shown at the top of My path, under the label Destination.
Write it as an outcome the member recognizes — Ship an AI agent that real users
talk to — not as a list of topics.
A milestone is a result the program expects: an objective, the proof you
expect, and what makes it a success. Your milestones, in the order of the
program's path, become the numbered steps of My path.
The order is the order you give the path. When you publish a new version of a
path, members already enrolled keep the version they started on.
A task is a piece of work you ask of every member: instructions, context,
how much it matters, and when it is due.
- A task attached to a milestone appears inside that step.
- A task without a milestone appears under Other actions, below the
steps. Use it for work that matters but belongs to no step — introducing
yourself to the community, booking a first call.
A task is created as a draft and members do not see it until you
publish it. Archiving a task removes it from members' paths without
deleting anything they already did.
Each task has one of three levels, shown to the member next to it:
| Level | What it tells the member |
|---|
| Required | This is expected of you. It is the default. |
| Recommended | You should do it; you can move on without it. |
| Optional | Useful if you have time. |
The member's execution progress counts published tasks only, level by
level.
A task has at most one deadline rule, or none:
| Rule | How it is set | What each member sees |
|---|
| Relative — D+n | a number of days | a date computed from their own enrollment date: D+14 is two weeks after they joined |
| Fixed | one date | the same date for everyone |
| None | — | no deadline |
A relative deadline follows the member: when an enrollment is paused with its
deadlines shifted, their D+n dates move by the length of the pause. A coach can
also extend one task's deadline for one member; that extension wins over
both rules, for that member only.
Once a task's deadline has passed, the member can no longer send a first
submission for it.
A task can expect a deliverable — the proof the member hands in: a file, a
link, or both, with the criteria it is judged against and the kind of person
who reviews it (a program director, a coach or a reviewer). A task has at most
one active deliverable.
- A task without a deliverable, the member marks as done themselves.
- A task with a deliverable is not ticked off by a click: it goes through
its submission and its review.
Each program has one unlock mode. It decides when a step of My path
opens.
| Mode | The next step opens when… |
|---|
| Immediate | always — every step is open from the start. This is the default. |
| Sequential | the member has completed every lesson covered by the steps before it. |
| Validation required | the deliverables of the steps before it have been validated by a reviewer. |
Three details decide most questions:
- All earlier steps count, not only the previous one. If step 2 was left
incomplete, step 4 stays closed even when step 3 is finished.
- A step with nothing to check counts as passed. In sequential mode, a step
that covers no lesson never blocks; in validation-required mode, a step whose
published tasks expect no deliverable never blocks.
- The member is told why. A closed step names the step to finish or, in
validation-required mode, the exact deliverable waiting for validation.
Coverage is how you say which lessons prepare a milestone: you attach
lessons (or resources) to it. It is what sequential mode reads.
- In sequential mode, coverage decides unlocking: the lessons a step covers
are the lessons to finish before the next one opens. A lesson attached only to
closed steps is closed too; a lesson attached to no milestone is always open.
- In immediate mode, coverage has no effect on the member side: nothing
is locked. It still documents, for you and your coaches, which content each
milestone puts to the test.
- In validation-required mode, what opens the next step is the review of
deliverables, not lesson completion.
When a task expects a deliverable, the member hands it in as a submission.
A submission moves through these states:
draft ──► submitted ──► in_review ──┬─► validated
├─► changes_requested ──► (new version) submitted …
└─► rejected
| State | What it means |
|---|
| draft | The member is preparing it. Only a draft can be edited. |
| submitted | Sent. It can no longer be changed, and it waits for a reviewer. |
| in_review | A reviewer has taken it; no one else will decide on it meanwhile. |
| changes_requested | The reviewer asks for corrections. The member sends a new version. |
| validated | Accepted. In validation-required mode, this is what opens the next step. |
| rejected | Refused, and final: no new version follows a rejection. |
Submissions are versioned, never overwritten. Each correction is a new
version next to the previous ones, and each review keeps its decision and its
feedback. A reviewer comparing versions sees what they asked for last time.
Who reviews. A person holding the reviewer responsibility for the school
reviews every submission; a coach reviews the submissions of the members
they coach. Owning or administering the school does not, on its own, make you a
reviewer: assign yourself the responsibility if you review too.
- Write the program's transformation — the Destination.
- Create the milestones, in path order.
- Attach the lessons that prepare each milestone (coverage).
- Add the tasks — in a milestone, or standing on their own — with their
level and deadline, and a deliverable where proof is expected.
- Publish the tasks.
- Choose the unlock mode.
All six steps can be done from the screens, or through the
API: programs,
milestones, member tasks
and deliverables.
