Capstone: Your 2026 AI Operating System

Your one-page record needs four connected parts:

A saved assistant is optional. The important connection is that the right brief receives current input and the output passes the intended checks.

Treat the workflow record as a set of connected decisions. A tool produces a draft; a person decides whether that draft meets the brief. Keeping those responsibilities visible makes it easier to recover when something changes.

For the fictional shop meeting, the first intermediate artifact is a fact list, not polished prose:

Each item must point back to the current notes. The next artifact is the structured draft:

Now apply the acceptance checks. There are three required sections. The decision stays separate from the discussion. The owner and date match the input. No marketing launch, budget approval or customer message has appeared. This short review is useful because it checks meaning at the exact point where a fluent draft could silently add a commitment.

The final artifact is a run note: “Meeting summary v1; source sample A; accepted after checking sections, decision, owner and deadline; illustrative manual rehearsal.” If you actually use a model, record that run instead. A folder containing only the final summary cannot show which source or brief produced it, so it is harder to diagnose later.

Suppose your next fictional meeting notes say no colour was approved, but the draft still says green. There are several possible faults. You may have pasted the old notes, left “green design approved” inside the saved instructions, or received an incorrect response despite correct inputs. The symptom alone does not identify the cause.

Inspect the actual input first. If it contains the old source, replace that source. If the source is current but the reusable brief hard-codes green, move the sample fact out of the instructions. If both are correct, reject the output and produce a corrected draft. Record the fault you observed rather than writing “the AI forgot everything.” These repairs affect different parts of the workflow and should not be mixed together.

There is also a useful stopping rule. After one targeted correction and another failed source check on this small task, use the manual three-section template. That is a proposed rule for this practice workflow, not a universal retry limit. Its purpose is to stop a short summary from becoming an open-ended debugging session.

The fictional first summary has passed review. Before anyone uses it, a correction arrives: “Sana will send the draft on Thursday, not Tuesday. Green remains approved.”

Predict the affected parts: List what needs updating before reading the answer. Does changing one date require replacing the tool, rewriting every brief, or checking the dependency between source and output?

Feedback: Keep the tool choice and general brief. Save the corrected source as sample A revision 2, change the Next steps date to Thursday, and recheck the resulting summary against that revision. Mark the earlier output superseded so a reader does not accidentally use Tuesday. Green and Sana remain unchanged because the correction did not alter them.

Your run note should identify both the corrected input and the newly checked output. A useful entry is: “Source revision 2 changes deadline only; Thursday checked; earlier Tuesday draft superseded.” This is the practical meaning of repeatability: another person can follow the same route and tell which result is current, including when an otherwise acceptable result has become stale.

Optional follow-on work includes adding more prompt-library entries, comparing a second tool, or configuring saved instructions. Use Lesson 4.3's usage log before paying for a feature. Keep an offline copy of approved non-sensitive briefs when permitted, so a connection problem does not erase your work.

If a real source changes, update it and retest the affected output. If you switch products, check the new account's permissions and features rather than assuming the old setup transferred.