Answerable Computing
Executing intelligence can be temporary. The ability to understand, challenge, and resolve its consequences must be designed to continue.
What answerability means
Answerable Computing is the design of systems in which consequential machine actions remain linked to the evidence, governing terms, and authority required for later inspection, challenge, and resolution.
Answerability is the system property. Accountability is the outcome when an authorized party can use those records and procedures to decide and act.
Before and after an executor
Authorization and funding can precede the executor they bring into existence. Review, payment, and settlement can follow its disappearance. A successor may be a person, a firm, or another temporary agent.
A retained account can supply evidence. It cannot, by itself, establish current decision authority or provide resources for a remedy. Those three requirements may sit with different parties, and each must remain reachable on its own terms.
Agent-to-agent succession has the same requirement: the next agent needs to establish what it may do, not merely recover what its predecessor believed.
Changing software and changing terms
Software replacement should not, by itself, enlarge a mandate, reset recorded spending, or erase an unresolved claim. Changes to terms require the authority specified by the governing arrangement.
Some arrangements depend on a particular supplier, model, or signer. Portable records do not remove those restrictions. A new application may reach a different reliance decision without thereby amending the agreement or deciding a remedy.
Continuity must also accommodate legitimate amendment, correction, discharge, and deletion. Preserve what remains applicable, record the basis for a change when required, and respect limits on access, purpose, and retention.
Affected parties may need recourse without having received a receipt. An accusation requires review; it must not automatically authorize an economic penalty.
Research design objective, not a rule implemented by the receipt format. How local reliance policy differs from agreed terms →
Liability is not a transaction record
The company behind an agent may remain legally responsible after the agent or model process stops. But responsibility alone does not reconstruct the transaction. The accepted request, operating limits, evidence, and decision authority may sit in different systems—or may never have been recorded together.
To pursue a dispute after the agents have been replaced, the parties need more than a saved result. They need the accepted terms, evidence they can examine, and a route to someone authorized to decide whether a correction or remedy is owed. A retained record supports that review; it does not supply judgment or legal authority.
From action to decision
- 01
Action
Software requests, performs, or authorizes consequential work under stated terms.
- 02
Record
Participants retain the request, limits, recorded authority, result commitments, and supporting evidence relevant to their roles.
- 03
Judgment
An authorized party evaluates the retained record under the governing terms.
- 04
Consequence
Payment, correction, or recourse follows only through authority established outside the record.
Participants may hold different evidence and reach different conclusions. Retaining records does not create mutual agreement or complete visibility. The record makes a later decision inspectable. It does not appoint the decision-maker or execute a remedy.
Where Bulla fits
Bulla supplies record tools. Existing workflow systems retain operating state; authorization systems govern access; payment systems execute transfers; logs and signed exports retain evidence. Each can contribute without adopting Bulla. Reduced integration burden and independent interoperability remain unestablished.
Bulla today
Creates and checks portable ActionReceipts locally, applies receiver-supplied reliance policies, reconciles receipts with customer records, and captures completed stdio MCP calls.
Bulla Labs research
Studies evidence custody, correction, witnessing, and recourse. These mechanisms are not part of the released package unless release evidence says otherwise.
Institutions
Customers, operators, forums, insurers, escrow services, and legal systems may provide authority or recourse. Bulla does not appoint them or determine their legal effect.
Independence and full cost
Practical exit includes replacing Bulla, a witness, a custodian, or a review institution. File portability alone does not ensure that another institution will recognize the record, possess current authority, or fund a remedy. Legitimate outstanding obligations and challenge rights must survive an authorized transfer.
Economics can reject machinery or deployment under the program’s constitutional commitments. A cheaper conventional arrangement may be sufficient.
Delegation can create the same continuity problem inside one organization. Even if inference becomes cheaper, transferring context, checking authority, and retaining evidence for unfinished work can still take effort. Bulla Labs asks whether shared record interfaces can reduce some of that overhead without retaining every intermediate computation. Read the economic investigation →