05 / 14VERIFIEDDescribes what runs today
Activity and accounting
Every request TAONIC serves leaves a durable record of its route and what it cost TAONIC. Nobody is charged, so the customer charge and revenue in every record are real zeros, not missing data.
| Component | State | Note |
|---|---|---|
| Durable request records | VERIFIED | One row per served request in D1, charge and revenue fixed at zero. |
| Provider spending guard | VERIFIED | A daily ceiling on TAONIC’s own spend; fails closed. |
| Append-only ledger | VERIFIED | Built and tested; one zero-amount entry exists from the sign-in proof. |
| Email sign-in | OFF | Proven end to end in production on 2026-09-21, then switched off. |
| Credits and charging | OFF | Built and tested, switched off; see 06 Pricing and charging status. |
Every request TAONIC serves leaves one durable row: its id, capability, route, provider, subnet, outcome, timing, provider-reported tokens and cost. Money is stored as integer micro-USD (integer micro-USD (1,000,000 = $1)); SQLite has no decimal type, and a float cent is a rounding bug in a ledger. The customer charge and revenue columns are written as zero by code that cannot write anything else, and the schema refuses negative values.
How a cost is classed
| Class | Meaning |
|---|---|
| PROVIDER REPORTED | The provider returned a figure for this exact request. |
| CALCULATED | The provider’s published rate, applied to the tokens it reported. |
| UNKNOWN | No rate and no report: counted, never priced, and never allowed to become a paid capability. |
Why a request was not answered
A record that was not answered says why, so a refusal is never counted as a provider failure:
| Category | Meaning | Provider cost |
|---|---|---|
| Provider failure | A provider was called and did not return a usable answer. | What that provider billed, if anything |
| Refused before a provider call | TAONIC’s own daily limit, or a plan no route could run. | None |
| Never completed | Opened, then the reader left or the server stopped before recording an outcome. | None booked |
| Recorded before outcomes | Closed before 2026-09-25, with a status that alone does not say which of the above it was. Never guessed. | As recorded |
- This browser: the Activity page lists the requests made from this browser tab, kept only in the tab and gone when it closes. Nothing there is sent anywhere.
- The service: the same page, and
GET /api/accounting, show the durable totals across every request and every server instance, from D1. - An account: none exists while accounts are off, so there is no per-account history yet.
Sign-in is by a single-use email link. The path was driven against the live site once, on 21 September 2026: the link was delivered, the click set a session cookie, a second click was refused, a signed-in question was recorded against the account with a charge of zero, and sign-out revoked the session on the server. Then accounts were switched off, because nothing in the interface offers sign-in yet and an open link endpoint would let anyone make a new sending domain send mail.
- The link is stored only as a hash, expires in 15 minutes and works exactly once.
- Asking for a link gives the same answer whether or not the address is known.
- The session cookie is HttpOnly, Secure, SameSite=Lax, and carries random bits only.
- Revocation is a database write, not a token that expires later.
- While accounts are off,
GET /api/accountreturns{"state":"OFF","signIn":false}and no sign-in control appears anywhere.
Every state on this page matches Status. Where they ever differ, Status is right and this page is a defect.