Files
tazlin 4063734bd1 docs(kudos): event retention explanation, reference and operations guide
- docs/explanation/kudos_retention.md is the entry point: the problem, the three readers of old rows and their replacements, the rejected alternative, partitions by age, the per-dataset replacement and archive table, one state diagram per dataset, properties and costs, a symptom table and a code map
- docs/reference/kudos_accounting.md gains the retention sections: catalog columns, states and step table, block reasons, configuration, archive objects, metrics and log lines, health fields, operator commands
- docs/how-to/kudos_ledger_operations.md gains the partition conversion, enabling retention with a held-drops soak and a grace period, rehearsing removal on a restored copy, handling blocked units, recovering from late rows or a chain gap, rolling back a removed partition, user statements and archive restore
- The explanation of kudos accounting links to the retention explanation instead of describing retention itself; the class index, topics page and site navigation list the new document
2026-11-03 12:32:56 -05:00

1.4 KiB

Explanation

Why the subsystems here are built the way they are: the problem each one solves, the alternatives that were weighed, and the properties the chosen design buys.

These pages give the shape of a design. A single choice, with its drivers and its consequences, is recorded instead in Decisions.

Documents

Document Summary
Kudos accounting, projection, and concurrency Why kudos movements are recorded as typed events, how the projector materializes them, and how spends stay safe while balances lag.
Kudos event retention Why the kudos event tables keep only an online window, what replaces older rows for each dataset, and what guards each irreversible drop.
Request feasibility and queue pressure Practical guidance for using request progress, worker compatibility, capacity counts, queue estimates, and stall warnings in API clients.
Chat requests on the Horde How chat requests use the text queue, worker capability declarations and a separate OpenAI-compatible front, with the design tradeoffs and client guarantees.