Questions, answered.
How recordation works, what the record can and cannot tell you, what stays private, and what it takes to start.
The basics8
What is recordation?
Recordation commits a record of what happened where no one can change it, so anyone who has to rely on it can check it. When an AI agent does a job, the party running it writes down what happened, as the work happens. On this page we call that party the operator. PacSpace commits the record out of the agent's reach, and out of the operator's control after the fact. The operator still says what happened. Recordation makes what they said fixed and checkable.
What does PacSpace actually do?
We make AI actions provable. When an AI agent does a job, a model answers, or a meter counts, the party running it writes down what happened, and we hold that record where no one can change it, us included. Anyone who has to rely on it can check it without asking our permission, and checking shows nothing of what's inside. We call that recordation.
What does “provable” mean? Isn't that an overclaim?
It would be if it meant true, and it doesn't. Provable means no one can change the record, PacSpace included; anyone who has to rely on it can check it without asking permission; and checking never reveals the data inside. It does not mean that what the operator wrote is true. It means what was written can't be changed afterward, and the people relying on it can see that for themselves.
What do you mean by a machine?
Any system that acts on someone's instruction and produces something another party has to rely on: an AI agent doing work, a model answering a request, a meter counting usage. The record is of what it did. This site leads with the agent. The usage meter was the first thing we recorded.
Is PacSpace a security product?
It works beside your security products and does a job they aren't built for: it lets someone outside your company check that a record hasn't changed. It is an integrity control on the record itself, and it composes with everything you already run; the perimeter protects where the record lives, we make what the record says checkable. In everyday words: your security tools guard the place the record is kept, and PacSpace lets anyone who relies on the record check that it still says what it said. Every breach plan assumes the logs will tell the truth about the breach. A committed record is how you show afterward that they haven't changed. Preventing, detecting, and responding stay with the tools and the team you have, and PacSpace replaces none of them. You may well file it under cyber, and that is a fair comparison and a fair procurement category.
Is it a logging or observability tool?
No, though it sits beside them. Those tools tell you what your systems saw, and they are good at it. The account they give sits under your control, so someone outside your company has to take your word for it. PacSpace keeps a record the outside party can check for themselves: that it was committed when it says, and that it hasn't changed since. Keep the tools you have. They tell you what happened. The record lets someone else check that what you told them hasn't changed.
Is PacSpace an auditor or an arbiter?
No. We don't audit, arbitrate, score, or rank, and we don't decide who is right. We commit the record. The people who rely on it read it, check it, and decide.
What is in production today?
The PacSpace Records API is in production: the company running an AI agent writes down each action as it happens, and anyone who relies on the agent can check it. The Shared Record is live for whoever a record is shared with. The Balance API, where PacSpace started, stays in production for usage bills. The way to judge it is to use it, and “How do we start?” below says how.
Labs and evaluators3
We're a lab. What do we hand an evaluator?
One link and a code, sent by separate channels. The link opens the record you chose to share, and the evaluator's browser checks every entry against the seal it was committed with. You choose what they see: the seals alone, chosen fields of an entry, or every field. Nothing about your systems goes with it, and nothing has to be installed on either side.
We're an evaluator. What do we need to check a record?
The link and its code, and nothing else. No account, no signup, nothing to install. The check runs in your browser the moment the record opens, and you can run it again on your own computer with our open-source checker, which works without PacSpace.
Can an evaluator see what the lab didn't reveal?
No. Fields the lab doesn't reveal can't be seen or guessed from the record. The evaluator sees how many were withheld, and checks every revealed field against the seal its entry was committed with. Withholding a field doesn't change what was committed: every entry's seal still checks, revealed or not.
The gap it closes4
What problem does this solve?
When an agent acts, the fullest record of what it did usually belongs to whoever ran it. Other parties may hold pieces, a payment here, an API call there, but the account of the work sits with the operator, often on systems the agent itself can reach. So when a customer, an auditor, or an investigator asks what the agent did, the answer comes from the party being asked, and that party has no easy way to show the account hasn't changed since. A committed record gives the people relying on the answer something they can check for themselves.
What does checking actually require?
Two things the author of an account can't supply alone: a copy the author could not have changed since it was made, and a way to confirm that without going back to the author. An agent's own log usually sits with its author, under its author's keys, and then it has neither, however well it is kept. That is the gap. It comes from where the log sits and says nothing about anyone's conduct.
We already ship logs to write-once storage and sign them. Isn't that enough?
Keep doing it. Those controls guard where your logs live, and they do that job well. The limit is who holds the keys. You hold the keys, so nobody outside can check them without asking you, and you can't prove to them that nothing changed, even when nothing did. A signature shows the log came from you. It doesn't show it is the same log you had last month, because whoever signs can also sign a rewritten one. PacSpace adds the part those controls leave open. Each entry is committed where neither you nor we can change it, and a reader outside your company can open the record and check each entry themselves, without your keys, your tooling, or a call to you, and without seeing more than you chose to show.
Why does the record have to exist before anyone asks?
Because a record made after the question can't show it was there before it. Pulling logs later works when everyone already trusts the logs. When they don't, nothing about an ordinary log shows that it said the same thing last month. A committed entry carries the time it was committed, and the operator doesn't set that time, so whoever reads it later can see it was there before the question was.
What the record can and cannot tell you10
Does the record prove that what was written is true?
No. The check shows the record is unchanged since it was committed. It does not show that what was recorded was true. We make claims fixed, not true. A fixed claim can be tested against everything else you know, and it can't be adjusted later to fit.
If the operator writes the record and pays you, how is it neutral?
Because neither writing nor paying buys a say over a committed entry. The operator writes, because the operator is the party that can see what the agent did. Once an entry is committed the operator can't revise or replace it, and we can't either, whoever is paying. The price is for recording capacity. It isn't tied to what a record says or to how any question about it comes out. The operator still chooses what to write and who to show it to, as with any record a company keeps. What the operator gives up is the ability to change it afterward, and that is the part a reader needs. Where the other side keeps its own record of the same work, the two can be compared.
What stops an operator from writing something false?
Nothing stops anyone from writing a false line, in any system. What PacSpace changes is what happens to it next. A false entry is fixed in place with its commit time on it, where it can be tested against other evidence, and it can't be reworded once someone starts asking. A log on the operator's own systems can often be revised without the revision showing. A committed entry can't be. We don't police what you write, and that is by design: PacSpace records and never decides. Our terms forbid false entries.
What if an entry never gets written, or the agent blocks the write?
Then the record shows a silence, and the silence is fixed in place. Where there are entries before and after, they are committed with their times, so the silence has a start and an end that can't be moved afterward. A gap in the record is as telling as a change. PacSpace can't tell you what should have been written: the record covers the actions that are written, as any log does. PacSpace doesn't detect the gap; whoever checks sees it.
Can the agent change the record?
No one can change the record, PacSpace included; it is committed out of the agent's reach. Two things an agent could still do, and you should plan for both. It could alter a copy it can reach, and a check of that copy would show the change. It would also show a committed entry dropped from the copy, because the count of committed entries is part of what the check reads. And if it can reach your write credentials, it could add entries of its own. It could not change or remove the entries already committed. So keep the write credentials where the agent can't get to them, and treat an entry you didn't expect as a signal. When a fact changes later, the fix is a new entry with its own reason, so the original and the correction both stay visible.
What about the time between an action and its commit?
An entry carries two times. One is when the operator says the thing happened, and that is the operator's word, like everything else in the entry. The other is when the entry was committed, and that one is not the operator's to set. What happened before an entry was committed is outside what the record can speak to, and that includes the moments the entry spends with us on its way to being committed. So the sooner you write, the less there is to take on faith, and once an entry is committed you can check it against what you sent.
Does PacSpace detect or stop anything?
No. PacSpace records and never decides, and that is what lets both sides rely on the same record. It doesn't watch your systems, raise alarms, say who did something, or stop anyone; your monitoring and your people do that. What it gives them is evidence that holds. When someone runs a check, the check shows whether a copy of the record still matches what was committed, and where it doesn't. Who changed it, why, and what follows are for the people who run the system and the people who oversee it to decide. Your monitoring raises the alarm. The record gives it a signal the machine can't erase. The change shows.
Can we check a record without going through PacSpace?
Yes. Opening a shared record in a browser is the easy way, and that page is served by us, so a careful reader shouldn't have to stop there. The operator can download a record's history file and hand it to you. A checker we publish on npm, under an open license, runs on your own machine, reads what was committed directly from the source, and compares it with the file. Neither PacSpace nor the operator is involved while that check runs, and you can read the checker's code to see what it computes.
What if PacSpace is breached, pressured, or simply wrong?
Breached: a breach of PacSpace could not change a committed record, because nothing inside PacSpace can. What we hold is small: your account details and what you wrote in your entries, encrypted in storage. The files and systems behind your entries are not with us, and an entry that carries references and no personal data leaves an intruder little to take. Pressured: if someone leans on us to change a record, we have no way to do it. If a court orders us to hand over what we hold, we are bound by that like any company, and our privacy policy says so. Wrong: if our software has a fault, a check is where it would show, and the check doesn't have to be ours. The checker in the question above runs without us.
What happens to our records if PacSpace goes away?
The seals stay where they are. They live on infrastructure outside any party's control, including ours, so what was committed doesn't depend on PacSpace existing. The contents of your entries are a different matter: we hold them to run the service, and if we were gone we would not be serving them. So keep your own copy. The operator can download a record's history file at any time, and that file stays checkable against what was committed, with the published checker and no PacSpace in the picture. Don't trust us; trust the math. The verification survives the company.
Privacy7
What leaves our systems, and what stays?
Your files and your systems stay with you. What leaves is what you choose to write in an entry: a title, a kind, a time, who acted, and any references, plus the ordinary account and access data our privacy policy lists. PacSpace holds that to run the service, encrypted in storage, and uses it for nothing else. An entry can point to a file by a fingerprint of it, a short code worked out from the file, and the file can't be rebuilt from that code. Someone who already holds the same file could tell that it matches. A good habit is to write references and leave personal data out.
Is anything published where others can see it?
The contents of your records are never published. What is committed where others can read it is a seal for each entry. The seal can't be turned back into the contents, and it is made so that guessing at the contents and comparing doesn't work either. Checking works the same way: to check a record you need the contents the operator shared with you, so a check shows you nothing you didn't already have and publishes nothing to anyone else. Showing the contents to anyone is the operator's deliberate choice.
If the operator decides who sees a record, how is checking “without asking permission”?
They are two different things. Seeing what a record says is the operator's choice: they share it with you, and they can take the link back. Checking is a different matter. With the link alone, the check runs in your browser on a page we serve, so you are relying on us for that page. With the record's history file, which comes from the operator, you check on your own machine against what was committed, and you rely on neither of us. What was committed sits on infrastructure no party controls, so once you hold the file, checking it needs no one's say-so. If you are relying on a record for something that matters, ask for the history file while the operator is willing to give it: a link can be revoked, and a file you hold can't.
Who can open a record, and do they need an account?
Whoever the operator shares it with. They open it from a link, with a code the operator sends separately. No account, no signup, nothing to install. The operator can revoke a link, and anyone holding it then sees that it is no longer active. The record itself does not change.
Is our data used for anything else?
No. We hold what you send in order to run the service you're paying for, encrypted and purgeable, and we use it for nothing else. We don't sell it. It reaches others in the ways our privacy policy and terms list, and in no others: the vendors who host and run the service for us under contract, a valid legal demand and the narrow legal cases beside it, a change of ownership of the company (you would be told), and anonymized totals used to improve the service. PacSpace charges for recording capacity, not for your data.
Would government work give any agency a view into our records?
No. Who else PacSpace serves doesn't change who can open your record: the people you share it with. An authority's route to what we hold is the one it has with any company, and our privacy policy sets it out.
What if something we wrote has to come out?
A committed entry can't be edited or removed, and that is the point of it, so the first rule is to keep personal data out of entries: write an order number, not a name. If something still has to go, what we hold of an entry's contents can be purged. What stays committed is the seal, which can't be turned back into the contents. The record will still show that an entry was there, and no longer what it said.
In practice9
What do we have to change?
You add a write where your system already logs what an agent did, in the code that runs the agent and not in anything the agent can rewrite. Your agents, your logs, and your stack stay as they are. PacSpace is not in the path of the action: the write reports something that has already happened, so the action doesn't depend on it. Whether your code waits for our reply is up to you. You can send it the way you send a log line.
What goes in an entry?
What you decide to write: a short title, a kind, the time it happened, who acted, and references to any files or earlier entries. For example: “Refund issued on order 88214, instructed by ticket 4417”, kind tool-call, actor agent-7. Because a committed entry can't be edited, write references and leave personal data out. What an entry says is yours. PacSpace doesn't read meaning into it, score it, or act on it.
We produce millions of log lines a day. Is this meant to take all of them?
No, and it doesn't need to. The record is for the actions someone will have to answer for: what the agent was told to do, what it changed, what it sent, what it handed to a person. Your logs keep the rest. Where the detail matters, one entry can stand for a whole log file: the entry carries a fingerprint of the file, so all of its lines are fixed by one write, and the file stays with you. Entries go in through an API with a rate limit for each workspace, so talk to us about volume before you design around it.
What if PacSpace is unreachable when the agent acts?
The action goes ahead, because PacSpace is not in its path. A write that doesn't commit is reported to you as not committed: nothing is half-written, and your earlier entries are unchanged. If you get no reply at all, treat the write as not committed and send it again when the service is back. Sending again is safe: the same write sent twice gives you the original entry, not a second one. The cost of an outage is time: the entry's commit time will say when it actually committed, so a late entry reads as late.
We wrote something wrong. Now what?
You write a correction. A committed entry doesn't change, so the fix is a new entry with its own stated reason, and both stay visible: the error, the correction, and why. What doesn't happen is an entry changing after the fact with nothing to show for it.
How do we start?
We would rather be evaluated by use than by description. Talk to us and we'll put you in a live environment set up for this: commit a record, try to alter it or any copy of it, then run the check yourself. The change shows. Bring the case you think breaks it. A good first case is one agent and one kind of action you already have to answer for.
What does it cost?
A subscription for recording capacity. The price isn't tied to what a record says, to how any question about it comes out, or to a percentage of anything. Talk to us for current plans.
What if we stop using PacSpace?
Download your records' history files before you go. What was committed stays where it is, outside our control and yours, so those files stay checkable with the published checker whether or not you are a customer. What we hold of your entries' contents is purgeable.
Where does our security team get its answers?
From us, in writing. Questions about hosting, access, certifications, and your security questionnaire are answered by the person accountable for our security.
Audit, regulation, and government5
Will our auditors accept these records?
It gives them what auditors tend to ask for: evidence held where it could not be revised, corrections visible as corrections, and a commit time the operator didn't set, which shows the entry existed by then. Your auditor can check all of that without an account or our help. Whether a given record is accepted is your auditor's call, as it is with any evidence. We don't replace your audit, and we don't judge whether an entry is right.
Where does PacSpace fit in the White House Accord's controls and audits?
PacSpace isn't one of the four layers, and it audits nothing. The accord, signed September 29, 2026, sets out internal controls, an internal team, an independent auditor or evaluator, and a board committee that receives their reports. PacSpace holds the record each of them can check: what your agents did, committed as it happened where no one can change it, PacSpace included. The accord is voluntary today, and PacSpace doesn't make anyone compliant with it.
Does a committed record carry legal weight?
A committed record has the properties a lawyer will ask about: each entry has a commit time the operator didn't set, it can't be altered afterward, and a reader can confirm both without relying on us. What weight that carries in a given matter is for your counsel and, in the end, a court. We don't give legal advice.
AI regulation keeps talking about logging and record-keeping. Does this help?
It helps with the part those rules keep coming back to: a durable account of what a system did, kept so that later changes would show. Recordation produces an account with that property. PacSpace is not a compliance product and doesn't make anyone compliant. Which rules apply to you, and whether a committed record meets them, is for you and your counsel.
Is this for government work too?
Yes, and the record works the same way with different readers. Where a machine acts for the government and its operator records it, the people responsible for oversight could check that record for themselves: that it was committed when it says and hasn't changed since. The operator still writes it. The Government page says what changes for oversight and how a program adopts it.
The hard questions5
Couldn't we build this ourselves?
You can build the logging, and you should. What you can't build is the outside party. Think of a notary: the stamp counts because the notary isn't the one signing, and nobody can notarize their own signature. It is the same here. If you design the scheme, run the infrastructure, and write the checker, then your customer, your auditor, or your regulator is checking you with your own tools, and you are back to asking to be believed. PacSpace is that outside party, and it is all we do. The record is committed where no one can change it, PacSpace included. The person relying on it opens it from a link and checks it with no account, nothing to install, and no call to you. On your side it is a write where you already log. And a record committed under one vendor contract is checkable after the contract ends, after the migration, and after the people who knew the system have left.
Won't the model labs, the clouds, or the agent platforms add this?
They may well add better logs, and that is good for everyone. What they can't add is distance from the work. A company that builds the model, runs the cloud, or sells the agent platform has a hand in what is being recorded, so a record it holds is its own account of work it took part in, however well it is kept. If you run agents across more than one model, cloud, or platform, a record kept by one of them covers its part and stops there. PacSpace has no other role in the work and sits across all of them, which is why it is a separate company, and why this is all we do. The test for anyone's record, ours included, is the same: can someone outside check it without relying on whoever holds it?
Are you saying the people running agents can't be trusted?
No, and nothing here assumes it. The point is about position: when an agent acts, the party running it has no easy way to show an outsider that its own log is unchanged, however carefully it was kept. The record is for the operator as much as for the reader. It lets an operator who kept a straight record show that the record hasn't moved since, instead of asking to be believed.
Is an agent changing its own logs a real risk, or a thought experiment?
It is documented. One case is written up, with links to its sources, in this field note. We don't retell it here, because the details matter and a summary would lose them. The note's title is something we were told. The note is clear that a record would not have stopped the break-in. Its point is what a record changes afterward: it is written as the work happens, where the agents can't reach it, and an attempt to change it shows when anyone checks.
What is under the hood? How does checking actually work?
What the record gives you, we will explain to anyone: entries committed at the time, not changeable after commit, checkable by anyone holding a copy, and seals that outlast us. How it is built is a conversation we have with your engineers when you evaluate it. And you don't have to take the check on faith: the checker we publish is code you can read, and it shows what a check computes and what it compares. You don't need the mechanism to test the claim.
When software buys4
Does this work when agents buy from agents?
Yes. It is the same record with two machines as the parties. When software is the buyer, often nobody is reading the bill as it builds, and reconciling by hand doesn't keep up with the speed software buys. Each side's activity can be recorded as it happens and checked by both counterparties and their auditors. PacSpace doesn't move the money. It records what each side said happened, where neither side can change it afterward.
Doesn't the payment rail already record everything?
It records the payment, and records it well: money moved, when, to whom. What the money bought is a different question. What was delivered, how much, and at what rate is written down by the seller, in the seller's books, changeable by the seller. The rail proves the payment. We prove what it paid for. “Prove” has the same narrow meaning here as everywhere on this page: what the seller said was delivered is fixed where both sides can check it. The details stay between the parties.
Is PacSpace part of x402?
No. x402 is a standard for software paying software over the web. PacSpace works alongside it the way it works alongside your billing stack: it sits beside it and is not part of it. The record is useful wherever software buys metered things, whatever standard carries the payment.
Is PacSpace a billing system?
No. PacSpace sits alongside billing. The provider keeps metering and invoicing exactly as they do today. PacSpace commits the record both sides reference, so the invoice points at a record both sides can check and not at one side's books.
Bring the case you think breaks it.
We would rather be evaluated by use than by description. Talk to us and we'll put you in a live environment: commit a record, do your best to change it, then check it yourself, with us out of the loop. The change shows.
The record must exist.