The quarterly review of a Kyber deployment: what gets checked

A distribution company, ten months after go-live. The server in the back room has not been down once. The agents draft the purchase orders every morning, a person approves them, the warehouse runs. Nobody from the supplier has been on site since the handover, and the monthly invoice for support arrives and is paid without anyone reading it.

Then the finance lead leaves. Her successor asks a simple question: what exactly does the system do on its own now, and who decided that? The operations manager opens the rules file in the repository. It describes the company as it was ten months ago. Two product lines have been added since, one warehouse has closed, and the approval limit in the file was written for a volume the company no longer does.

Nothing is broken. That is the problem: a system that never breaks is never looked at, and the distance between what the rules say and what the business does grows quietly every week.

The cause is not negligence on anyone’s part. A support contract written around incidents only creates contact when something fails. A deployment that runs well produces no incidents, so it produces no contact, and the supplier’s picture of the company freezes on handover day. The fix is structural: the contract has to schedule the looking, with an agenda nobody can skip because things seem fine.

What drifts when nobody schedules a look

The rules fall behind the business. The policy file for the agents was written with the people who held those decisions at the time. People change roles, limits change, processes get added. A rule that still says “orders above this amount wait for a person” keeps the amount of a different year, and a rule for a process that no longer exists keeps running against data nobody looks at.

Access outlives the people. Someone joined, moved desks, took over a process and left. Each step was handled in the moment and never reconciled. A year in, the list of identities that may read customer data includes two contractors, one of whom finished in spring, and a shared account someone created during an incident “just for now”.

Models get updated and nobody re-reads the evaluations. A model version changes, usually for good reasons. The evaluations that were run before go-live were run against the old one. Whether the forecasting agent still behaves the same on your data is not known until someone asks, and nobody asks while the numbers look plausible.

Backups are taken and never restored. The job runs nightly and reports success. Success means a file was written. Whether that file restores into a working system, with the current configuration and the current rules, was last proven on handover day, if then.

The exit becomes theoretical. The contract says what is handed over on exit, in which formats and within how long. If that procedure has never been run, nobody knows whether the export still works after the last three updates, and the clause that was meant to keep the supplier honest is a paragraph nobody has tested.

The customer stops learning. The handover left the team able to run the routine. Twelve months later, the two people who sat through it have moved on and the runbook describes screens that have since changed. The team can call support, so they call support, and the knowledge the contract was supposed to transfer lives with the supplier again.

What the review should contain

The useful version is a fixed agenda, the same every quarter, written into the contract so that skipping it is a breach rather than a scheduling choice. Each point produces a short written result: checked, changed, or deferred with a reason.

1. Rules against reality. Walk through the policy file with the people who own the decisions now, not the people who owned them at go-live. Every rule is either confirmed, changed, or retired. The diff goes into the repository with the date.
2. Identities and access. Every account, every agent identity, every KyberCell network rule, matched against the current list of people and processes. Anything without a named owner is removed, not parked.
3. Model versions and their evaluations. Which versions run today, what changed since the last review, and whether the evaluations were re-run against them on the company’s own data. A version with no fresh evaluation is a finding, not a detail.
4. A restore, not a backup report. Pick one backup from the quarter and restore it into a separate environment. Confirm the configuration, the rules and the data come back as they should, and write down how long it took.
5. Exit readiness. Run the export the exit clause describes, in the formats it names. Check that what comes out could be handed to another team and understood. A clause that has been rehearsed is a clause that works.
6. What the customer can now do alone. List the operations the team performed without support that quarter, and the ones they called about. The second list is the training agenda for the next quarter, and it should shrink.

A test you can run this week

Open your support contract and search for the word “review”, or “quarterly”, or whatever your supplier calls it. If there is a clause, read what it obliges them to check and compare it with the six points above. If there is no clause, ask your supplier for the date of the last time anyone restored a backup from your system into a working environment.

If the answer is a date, you have a review in practice even if not on paper, and the next step is writing it down. If the answer is that the backups run every night and report success, you have learned what the contract does not cover, and you learned it on a quiet day rather than the other kind.

A support contract from KYBERTIS is meant to include a review of this shape, scheduled and documented, with the exit clause rehearsed as part of it rather than filed. Where the contract came from, and why it has no price list, is the subject of the next post.