A Stack that worked in March produces confidently wrong documents in September if nobody updated the price list. Maintenance is three checks, triggered by events in the business instead of a calendar reminder nobody honours.
Key takeaways
- Update the Source layer on business events: price changes, new services, changed terms.
- Add to the Rules layer whenever something gets through that should have been flagged.
- Context and Task layers almost never change. Output changes when your documents change.
- Keep a short log of what broke and what fixed it. It becomes your Rules layer.
- Re-test against a known job after any change, not on a live one.
The three triggers
| Trigger | Layer to update | Why |
|---|---|---|
| Prices, rates or fees change | Source | Stale prices produce confidently wrong quotes |
| A new service or product launches | Source, then Rules | Otherwise the Stack omits it or invents its scope |
| Terms, warranty or policy changes | Source | Old terms in a customer document create a dispute |
| Something wrong got through | Rules | Every failure names a missing limit |
| Your document format changes | Output | Otherwise staff reformat every run and abandon the Stack |
| Staff turnover on that job | Ownership | An unowned Stack decays silently |
Nothing on that list is a date. Maintenance driven by a monthly reminder gets skipped. Maintenance driven by "we changed our prices today" happens, because someone is already in the document.
The failure log
Keep one short list per Stack: what came back wrong, and the rule that fixed it. Two columns, a few lines a month.
That log is the most valuable artefact in the whole system. It is an accumulating record of your standards, written in the exact form a new staff member or an AI assistant can use. Businesses that keep it end up with reliable workflows. Businesses that fix things verbally end up fixing the same thing four times.
How to re-test after a change
Use the same known job every time. Run it, compare against the document you actually sent for that job, and look only at the thing you changed. Changing three layers and declaring it better teaches you nothing about which one mattered.
If the output degrades, the previous version of the layer is your rollback. Keep the last version in the document, below the current one.
The stale-source check
The quiet failure mode is the workflow that still runs perfectly and quotes last year's prices. Two protections. First, date the Source material inside the Stack so anyone can see how old it is. Second, put the price check in the human review step, so the person approving the document is also confirming the figures are current.
Testing and maintaining workflows in general, or how to check output before it goes out.
Who owns it
One person per Stack. Their job is the Source layer and the failure log. Without a named owner every layer drifts, and the first sign is usually a customer asking about a price nobody charges any more.
Keep yours current with the team
Private onsite training sets up Stacks with the people who do the work and names the owner for each one, at your workplace, scoped for roughly 4 to 20 people. Enquire about team training, or see the public workshop.
Frequently asked questions
How often should you review a Context Stack?
On business events instead of a schedule: price changes, new services, changed terms, or a failure getting through. A quarterly glance at the Source layer catches anything missed.
What is the most common maintenance failure?
A stale price list. The workflow keeps running and the output is confidently wrong, which is harder to spot than an obvious error.
How do you know a Stack is degrading?
Review time creeps up. If the person checking the output starts editing more each week, a layer has drifted.
Should you version a Stack?
Keep the previous version of any layer you change, below the current one. That gives you a rollback without any tooling.
Who should own maintenance?
The person who does that job most often. Ownership is the Source layer and the failure log, not technical skill.
What if the business changes completely?
Then rebuild the Stack from the template rather than patching it. Context and Task will both have moved. Start from the template.