# 7. My AI operating system

Michael Rainer · APEX-PRESS · v0.37-C01 · EN

Use these eight references alongside the chapters. Copy the fields you need into your own record and keep one working version of that record. A reference card can remind you what to check; completing its fields does not prove that the answer is correct. Examples below are author-written practice material unless explicitly linked to the dated observations in Day 28.

This is a record of your chosen workflows, not software you must install. Use the evidence you accumulated in Days 7, 14, 21, 28, and 30. If you did not test a candidate, mark it not tested. The book's examples cannot establish that it works for you.

Start with up to five candidates. You may retain fewer or none. Each row needs a reason tied to actual work rather than the popularity of a tool or your enthusiasm for a particular answer.

| Candidate | Actual evidence and result | Checking and correction effort | Status | Reason |
| --- | --- | --- | --- | --- |
| 1 | Locate request, output, and finished work | Measured or explicitly unknown | Keep / change / drop / not tested | Explain the decision |
| 2 | Locate request, output, and finished work | Measured or explicitly unknown | Keep / change / drop / not tested | Explain the decision |
| 3 | Locate request, output, and finished work | Measured or explicitly unknown | Keep / change / drop / not tested | Explain the decision |
| 4 | Locate request, output, and finished work | Measured or explicitly unknown | Keep / change / drop / not tested | Explain the decision |
| 5 | Locate request, output, and finished work | Measured or explicitly unknown | Keep / change / drop / not tested | Explain the decision |

For each retained workflow, make one procedure record. State the purpose and what counts as finished. Describe the suitable starting situation, inputs, source versions, and permission boundary. Record the actual tool or manual method, visible conditions, and date checked. Add the reusable request, the checks you perform, and the decision you retain.

Then write the stop conditions and fallback. “Missing applicable original” is a recognizable stop condition. “Be careful” is not. “Use the verified factual fields in my plain invitation template” is a usable fallback. “Do it another way” may leave you starting from nothing when the workflow fails.

Keep the result and effort log where the procedure can point to them. The record should help you distinguish a workflow that has been tested from one you have merely described. A successful result also has a scope: the procedure applies to that kind of task under the conditions you checked.

Finish with a review date and the changes that would bring the review forward. A new input format, more sensitive information, an important error, or changed guidance may matter. Writing a date here does not create a calendar event, reminder, or automatic monitor.

Add two final lines to your page: “A decision I continue to make myself” and “A task I can complete without AI.” These are part of maintaining the system. You should be able to understand its purpose and its fallback without consulting the assistant that helped write the record.

If several candidates rely on the same source, check, or permission, note that shared dependency. Updating it once may affect more than one procedure. If the dependency is unresolved, do not distribute a “Keep” label across every affected row merely because the outputs look different.