Two lines to record it. One link to check it.
Add a write where your system already logs what an agent did. Your agents, your logs and your stack stay as they are, and nothing sits in the path of the action.
How the record gets made.
- 01An agent actsIt calls a tool, opens a connection, changes a file, or hands work to a person.
- 02The operator writes the recordYour system writes the entry where it already logs, as the work happens.
- 03PacSpace commits itOut of the agent's reach, and out of your control after the fact.
- 04Anyone who relies on it checks, without askingAn evaluator, an auditor, your board, a customer.
You write the record. Nobody on the other side has to sign up, install anything, or agree to anything first. They just check it.
Where your system already logs.
const { ref, blinding } = await fingerprint(output);
await pac.records.emit({ record: 'run-4417', actorId: 'agent-7',
title: 'Robot r-112 stopped', occurredAt: t, payloads: [ref] });Install the SDK, paste a key, and add the two lines where your system already logs what an agent did. A pk_test_ key writes to your Sandbox and a pk_live_ key to Production; the key decides the environment. Sandbox and Production run on separate systems, so a test never touches a live record.
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.
What leaves your systems, and what stays.
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.
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.
You choose what each reader sees.
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.
It adds a record and replaces nothing.
Keep them. Write-once storage and signed logs keep doing their jobs, but 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. The record adds the part an outsider can check. More in the FAQ
Attestation shows where an agent ran and which code it ran. PacSpace adds a record of what the agent did, and anyone who relies on the agent can check it.
Guardrails decide what an agent may do. PacSpace doesn't decide anything. It commits the record of what the agent did and what its guardrails decided, so anyone who relies on the agent can check it.
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.
One agent and one kind of action.
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.
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.