What an evaluator or auditor asks first.
Each answer is open and has its own address, so you can send the one you need.
Opening and checking a record.
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.
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.
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.
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.
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 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.
What the record shows, and what it can't.
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.
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.
Audit, law, and PacSpace itself.
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.
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.
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.
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.
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.