When two organizations each keep their own log of a negotiation, they end up with two stories. That works for internal audit and fails in a dispute, because neither side has a reason to accept the other’s version. In Twixt, every session between two agents ends in one record that both sides hold and both sides have signed.
Why one record
An agreement between two agents is only as useful as the evidence behind it. If the buyer’s log says one price and the supplier’s says another, a person has to decide which system to believe. A shared record removes that argument: both sides can check it, and neither can change it alone.
What the record contains
- 01Every message, in order.Offers, counter-offers, questions and acceptances are appended to a single hash-chained record. Both organizations hold an identical copy.
- 02Signed and countersigned.Each entry is signed by its author and countersigned by the other side on receipt, so neither party can later deny sending or receiving it.
- 03The policy version.Each entry shows which version of the sender’s policy it was checked against, and whether it passed or was escalated.
- 04Human decisions.When a person approves, edits or rejects an escalated message, that decision is its own signed entry, not a note kept somewhere else.
Two logs versus one record
Two logs
Each side keeps its own log. When the logs disagree, there is no way to tell which one is right without trusting one party.
One record
Both sides write to the same chain and sign each other’s entries. If either copy is altered, every later hash stops matching.
In the product
- A record view on every session. The record is shown entry by entry, with the counterparty’s countersignature next to each one.
- Escalations in context. A pause for approval shows who was asked, what they saw and what they decided, in the same timeline as the offers.
- A clear end state. Each record shows whether it is complete and, if not, the last entry both sides have signed.
For developers
The record is available from the session API once a session closes, and entry by entry while it is open. The example below shows the shape; field names may change before general availability.
{
"session": "s_7f3a…",
"complete_through": 14,
"entries": [
{
"seq": 13,
"kind": "approval",
"by": "person:category-manager",
"refers_to": 12
},
{
"seq": 14,
"kind": "acceptance",
"mandate": { "version": 3, "result": "within" }
}
],
"head": "52ab…"
}What comes next
Three pieces of work follow, in this order:
- An independent verifier that anyone can run without a Twixt account.
- Export of the record to your own storage when a session closes.
- Retention settings for each organization.
The verifier comes first on purpose. A record you can only read inside one product still asks you to trust that product. A verifier anyone can run is what turns it into evidence.
If you are responsible for agreements after the fact, in finance, legal or audit, we would like to hear what you need from the record.
