Case Studies on XKV.org

A Credit Limit Dropped From 100 to 50 and XKV Shows the Three Steps Behind It

Mon, 19 Oct 2026 00:00:00 +0000

A customer calls support. Their credit limit was 100 yesterday and it’s 50 today, and nobody told them why. The support agent can see the 50. Everything else is spread across three services.

The limits service set the 50, under its risk policy. The risk model raised the account’s score the day before. Billing had recorded a chargeback from the bank that morning. Each service did one reasonable thing, and each logged it in its own way. Putting the story together means knowing which logs to open and in what order.

A Q4 Price List Goes Out as One Transaction With One Reason

Mon, 19 Oct 2026 00:00:00 +0000

Prices change together. A new quarter’s price list touches every plan at once, and a half-applied list is worse than an old one: for a few minutes Pro might cost less than Basic. The list also has one reason behind it, usually a decision made in a meeting, with a ticket that tracked the rollout.

XKV writes the whole list in one transaction. Every price commits or none does, and every price carries the same reason, ticket and cause, given once.

A Timeout Raised During an Incident Explains Itself Three Weeks Later

Mon, 19 Oct 2026 00:00:00 +0000

At two in the morning an alert fires: the orders database is answering slowly, and order requests are timing out. The on-call engineer raises the database timeout from 5 seconds to 30 so requests stop failing while a replica catches up. It works. The alert resolves. Everyone goes back to bed.

Three weeks later someone notices the timeout is 30 seconds and wonders whether that’s a typo. Changing it back might be right. It might also bring the incident back. The person who knows is on holiday, and the incident channel has scrolled far out of sight.

An AI Agent Changed a Cache Setting and XKV Kept the Tool Call Behind It

Mon, 19 Oct 2026 00:00:00 +0000

An operations agent watches the product catalog. Its metrics show 4.1% of reads returning stale data, above the 2% target, so it shortens the catalog cache’s time-to-live from 300 seconds to 30. That’s a reasonable move. An hour later the catalog database is at 91% CPU, because the cache now sends ten times as many reads its way. An engineer puts the TTL back.

The next morning the team wants to know what happened. The questions are the usual ones, with a new twist: which change did the agent make, what was it looking at, and which of its tool calls did it? Agents act fast and often, so their changes need a trail at least as good as a person’s.