What a program office asks first.
Ten answers, grouped. Each one has its own address, so you can send the one you need.
Writing and reading the record.
Who writes the record, and can the operator leave things out?
The operator writes it, as the work happens, because only the operator's system sees the work. That may be the contractor or the agency, whoever runs the system. The operator still chooses what to write, the same limit every log has. What it gives up is changing the record afterward. If writing stops, the gap shows: the records on either side put a start and an end on it.
Can oversight read what's inside?
Only what the operator reveals. A reader sees every seal, in order, and a count of what was withheld, and checks each revealed field against its seal. Checking never shows a field the operator kept back.
What does PacSpace hold, and what leaves it?
PacSpace holds what the operator writes in an entry, to run the service, encrypted in storage, and uses it for nothing else. What leaves PacSpace is each entry's seal, committed to the proof layer, infrastructure no party controls, PacSpace included. A seal shows that an entry was made and when, and nothing about what it says. A good habit is to write references and leave personal data out.
Checking it.
Can a reader check without going through PacSpace?
Yes. The operator can hand over a record's history file, and our open-source checker reads what was committed directly and compares it with the file on the reader's own machine. Neither PacSpace nor the operator is involved while that check runs. If PacSpace went away, the seals would still be there, and the history file would still check.
What is the proof layer, and who runs it?
Infrastructure no party controls, PacSpace included. Each seal is committed there, and the checker reads it from there directly. We take a program's technical reviewers through exactly what the design trusts, in a technical review.
We already keep write-once logs and sign them. Why add this?
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 committed entry is out of everyone's reach, PacSpace included, and a reader outside the program checks it without your keys, your tooling or a call to you.
What if an intruder gets the system's write credentials?
They could add entries of their own from then on, and those entries would carry their times. They could not change or remove the entries already committed. So keep the write credentials where the agent, and anyone who reaches it, can't get to them, and treat an entry nobody expected as a signal.
Buying it.
How does a program start?
Talk to us, or ask the prime contractor that delivers your program to. Evaluation starts unclassified, on the platform as it stands: a test record with no controlled information in it, a copy changed on purpose, and a check run the way the program would run it. How we work with a prime
Does this make our system compliant or authorized?
No. PacSpace is not a compliance product and doesn't make a system compliant or authorized. It gives a program a record anyone it chooses can check. What that record satisfies on a given system is for the program, its assessor and its counsel. What federal policy already asks for
How is it priced?
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. No fee rides a finding, an incident or an audit result.
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.