What a lab asks first.
Each answer is open and has its own address, so you can send the one your team needs.
What the record shows, and what it can't.
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.
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.
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.
Why it holds, and what PacSpace won't do.
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.
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.
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.
Who sees what.
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.
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.
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.
For security, audit and legal.
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.
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.
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.
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.
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.