Docs preview

How Tallyback works

Full documentation will ship with the public repository. This page summarizes the model so you know what to expect.

Three layers

• Core runs the transaction loop and its safety rules: validation, policy, idempotency, observation, verification and audit.
• Profiles define one industry’s vocabulary: resource types, actions, state, legal transitions and what counts as proof that an action happened.
• Adapters talk to one vendor system each. They observe a resource and execute a plan. Vendor details never reach the core.

The loop

1. Intent. An app or an AI agent sends an Intent. It names who is asking, which record to change, the outcome they want, and an idempotency key so the same request can never run twice.
2. Check. Tallyback observes the record as it is right now, checks policy, and confirms the change is a legal next step. Anything that fails a check is rejected before a single write happens.
3. Act. An adapter carries out the change in the outside system. Vendor endpoints, field names and statuses live in the adapter, never in the core.
4. Read back. Tallyback reads the outside system again on its own. The reading has to be fresh and has to belong to the same record, or it does not count.
5. Compare and record. Tallyback compares what it read with the outcome that was asked for. It returns a Result and writes audit events whether the answer is yes or no.

Results

• VERIFIED: the post-action read-back shows the requested outcome. An API success response alone never produces VERIFIED.
• FAILED: the adapter proved that no change happened.
• INDETERMINATE: the outcome could not be confirmed. The resource stays fenced and is never retried automatically.
• REJECTED: the request failed validation, policy or a transition check before anything was written.

Install

npm install tallyback Coming soon · not on npm yet

← Back to tallyback.dev