What this is: Practical guidance for maintaining LC-OS governance over time. The hardest part of any system isn't starting — it's continuing when you're busy.
Every governance system follows the same decay pattern without active maintenance:
Week 1: Files current. AI has perfect context. Work flows well.
Week 3: Files slightly stale. AI uses outdated context. Minor drift.
Week 6: Files significantly stale. AI makes decisions based on old assumptions.
Week 10: Files abandoned. Governance is theater. Problems multiply.
LC-OS breaks this pattern with one rule:
Update the files before you close the session — not after, not later, now.
This is the single most important discipline in the system.
After every AI session that produced a decision, correction, or number change:
- Open the running document
- Add any decisions made (even small ones) to the Decisions Log
- Add any corrections to the Corrections section
- Update "Last updated" date
- If any number changed — open canonical numbers and update it
Total time: 2 minutes if you do it now. 20 minutes if you wait a week.
Use the Weekly-Review-Checklist.md to run a structured audit.
When: Once per week, same time every week.
Minimum acceptable: Once every 10 days.
Red line: Never let files go more than 2 weeks without review.
Run this monthly or after any significant project change.
- Read your strategy master from start to finish
- Ask: "Is this still accurate? Are these still the right principles?"
- Review your failure log for patterns — are the same types of failures recurring?
- Check if your success criteria are still the right targets
Fix: Make it a closing ritual, not an extra task. Before you close your laptop after a work session, your rule is: "Running document updated? Canonical numbers updated?" Two checkboxes. Not a project. A habit.
Fix: The AI doesn't have memory between sessions. Rules only persist if you put them in the running document and share it at session start. If the AI is forgetting something — ask yourself: "Is this in my running document?" It probably isn't.
Session start template (copy-paste this):
Here is my running document and canonical numbers for this project.
Please read both before we begin.
[paste running-document.md]
[paste canonical-numbers.md]
Let's continue from where we left off.
Fix: Archive superseded values rather than deleting them.
Mark old rows as [SUPERSEDED: replaced by X on DATE] and move them to a
"History" section at the bottom. The working section stays clean; the history
is preserved.
Example:
| Price | $9/month | Current |
| ~~Price~~ | ~~$12/month~~ | [SUPERSEDED: changed 2026-02-12, see above] |Fix: At the end of every session, before closing, ask: "What decisions were made in this session?"
If you worked with AI, you can ask the AI directly: "Summarize the decisions we made in this session so I can log them."
Log them in the running document before closing.
Fix: This is a signal that your strategy isn't settled yet. That's fine — but you should treat unstable strategy explicitly:
- Mark it DRAFT in the Document Control section
- Don't share it with the AI as if it's authoritative — share it as context with the caveat "this is still being defined"
- Once you've validated the core logic (usually after first real user/customer data), promote it to ACTIVE
An unstable strategy master is better than a false stable one.
Fix: Reframe what the failure log is for.
The failure log is not a record of your mistakes. It is a record of your system working. Every entry shows: something went wrong, you caught it, you fixed it, you made the system better. That is not failure — that is engineering.
The projects without failure logs don't have fewer failures. They have less visibility into failures, and the same mistakes repeat.
Print this and keep it at your desk.
Before closing any AI work session:
□ Open running-document.md
□ Add any decisions made → Decisions Log
□ Add any corrections → Corrections section
□ Update "Last updated" date
□ If any number changed:
Open canonical-numbers.md
Update the row(s)
Add to version history section
□ If something went wrong:
Add entry to failure-log.md
Total: 2 minutes
Before starting any new AI session, ask yourself:
- If I share my running document right now, does it reflect what's actually true?
- If I share my canonical numbers right now, are all the numbers current?
- Are there any decisions made since the last update that my AI doesn't know about?
If yes to any of these — update before starting. Two minutes now saves twenty minutes of correction later.
- Sessions start quickly because context loading is fast
- The AI rarely asks you to re-explain things it already "knows"
- When the AI makes a mistake, you catch it quickly because you have reference documents
- Decisions feel traceable — you can always answer "why did we do this?"
- Failures are caught early and fixed cleanly
- You trust the system, so you offload more to it, so you work faster
- Every session starts with 10–15 minutes of re-context-setting
- The AI uses numbers or facts you've already corrected
- You're not sure which version of a decision is current
- Failures recur because they were fixed in conversation but not in the system
- You start to distrust the AI, so you do more yourself, so you work slower
The files are not the work. They are the infrastructure that makes the work reliable.