2.3 Capture and commit.

Why it exists

A useful system must reliably receive the emails, notes, requests, and changes that affect the work, otherwise the AI is helping with last week’s reality. Capture must also be cheap: a route costing more than 30 seconds per input will be abandoned within a month, and abandoned capture is worse than none because the system looks fed while starving.

Questions

1. Which two input routes matter most right now?
2. What kinds of inputs arrive through each route?
3. Walk me through the last time an important input arrived and got lost. Where did it go missing?
4. Where should captured inputs land?
5. Who reviews the capture queue?
6. How often should it be reviewed? (The Session Protocol’s boot sequence is the reader, see Protocol Module B.)
7. How long does capturing one input take today? If it takes more than 30 seconds, what would make it faster? (A route that cannot be done in under 30 seconds fails the design test.)
8. What metadata must be preserved: source, received time, sender, input type, and original link?
9. What counts as a duplicate?
10. How should ambiguous dates, owners, or requests be handled?
11. Where should failed captures be recorded?
12. What retry rule should apply?
13. What consent or privacy requirements apply?
14. Which inputs are prohibited?
15. Which fields may AI propose from the captured input?
16. Which fields require human confirmation?
17. What does “reviewed” mean?
18. What should happen to the original input?
19. (Frontier only) Which AI conversations contain decisions or facts worth distilling into the daily log, and who reviews the distillation before it lands?

Build prompt

Using the interview answers, create a capture and review protocol.

Include:
- Selected input routes (two) and destination
- Review owner and cadence (naming the boot sequence as the queue's reader)
- Required metadata; the 30-second capture rule per route
- Duplicate rule; ambiguity rule; failure record and retry rule
- Privacy and consent boundary; prohibited inputs
- Candidate fields AI may propose; fields requiring confirmation
- Reviewed status definition; original preservation rule
- Handoff: how reviewed items reach the daily log (Interview 3) and the
  commitment system (Interview 5)

Keep the process usable in existing tools, no new connector unless already
justified. Separate approved facts / proposed rules / assumptions / unanswered
questions / evidence needed; mark assumptions unconfirmed.

Test

Send ten approved test inputs through the two routes:

1. Eight normal inputs, pass if every one has an accounted-for result and capture time is under 30 seconds (time it).
2. One duplicate, pass if identified and not double-processed.
3. One ambiguous date (“let’s meet end of month”), pass if the item waits for review rather than guessing.
4. One safe simulated failure, capture an input while the destination is deliberately made unavailable (point the route at a read-only copy, or disconnect the destination for the test). Pass if the failure appears in the failure record with timestamp, input identity, and retry status, and nothing is silently dropped.
5. One real input, pass if it reaches reviewed status through the actual cadence.

Done

Depth by stage

Intermediate runs two manual routes with no new tooling. Expert routes failed captures into the operator’s escalation queue. Frontier may add one conversation-distillation route (AI sessions distilled to the daily log, human-reviewed), route count is capped by evidence of use.

Why it exists

Captured information becomes useful work only when commitments have owners, next actions, dates or explicit uncertainty, and review status. This interview also draws the commitment/suggestion line, the cheapest way an AI-assisted system creates damage is quietly promoting someone’s “we should probably” into your obligation list.

Questions

1. Which existing task system will remain the source of truth?
2. Why is that the system people will actually check?
3. Walk me through the last commitment that fell through the cracks. Where was it recorded, if anywhere? Who noticed, and when?
4. What fields should each accepted commitment have?
5. How should explicit commitments differ from suggestions?
6. Who confirms ownership?
7. What happens when no owner is clear?
8. How should due dates, review dates, and uncertain dates be represented?
9. How does the task system relate to the existing calendar?
10. How should dependencies be recorded?
11. How should changed deadlines be reconciled with the source?
12. How should duplicate requests be matched to existing tasks?
13. What evidence confirms completion?
14. How should completed work be closed without losing history?
15. Who reviews urgent commitments?
16. When are open loops reviewed? (This feeds the weekly review in Protocol Module B, name the day and time.)
17. What should happen to suggestions that are not accepted?
18. Which task updates may AI propose?
19. Which task updates require human confirmation?
20. What is the maximum number of newly systematized commitment behaviors you will take on this review period? (Cap: two. More than two new habits at once is how systems die.)

Build prompt

Using the interview answers, create commitment-tracking rules for this workflow.

Include:
- Source-of-truth task system
- Required fields per commitment: owner, next action, source, status,
  due-or-review date (or explicit uncertainty), dependency
- Explicit commitment versus suggestion rule; ownership confirmation
- Due date and uncertainty handling; calendar relationship; dependencies
- Source reconciliation rule; duplicate rule; completion evidence rule
- Open-loops review cadence (day and time, feeding the weekly review)
- AI proposal versus human confirmation boundary
- The two-new-behaviors cap for this period

For every accepted commitment created in this interview, write an implementation
intention line, "When [cue], I will [next action]", and rehearse each once
with me before the session ends.

Do not create a competing task system if an existing one works. Separate
approved facts / proposed rules / assumptions / unanswered questions / evidence
needed; mark assumptions unconfirmed.

Test

Process five concrete inputs:

1. Explicit commitment (“I will send the revised quote by Thursday”), pass if it becomes a task with owner, next action, date, source.
2. Suggestion (“we should probably revisit the pricing page someday”), pass if it remains a suggestion and creates no obligation.
3. Duplicate request, pass if it matches the existing task without creating a second.
4. Changed deadline, pass if the task updates and reconciles against its source (the original request, not memory).
5. Completed item, pass if it closes with evidence, no longer appears open, and history survives.

Done

Depth by stage

Intermediate installs the rules and the weekly open-loops review. Expert adds the current-quarter priorities page that commitments link to. Frontier re-checks, in the portability run, that the task system, not the AI tool, remains the source of truth.