How recordation works, where the gap is, what stays private, and what happens when software does the buying.
Recordation commits the usage to a record before the invoice goes out. Both the provider and the customer can open the same record, and it reads the same for both. The provider still produces the numbers. Recordation gives both sides one shared copy to work from.
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 has a shared source instead of a one-sided one.
It records. It commits the usage to a record before the invoice, keeps that record consistent for both sides, and lets each side check it directly. It does not decide who is right.
Two parties, one number, and only one of them can see how it was made. That is every usage bill today. The customer's choices are to take the number on faith or to fight it, and both are expensive: faith caps how much they are willing to spend, and fighting burns weeks on both sides. A record both sides can check adds the third option: check it. Questions become lookups instead of arguments, and the number stops being a matter of trust at all.
One party measures the usage, produces the invoice, and holds the only record of what happened. The customer reads that number through the provider's dashboard or export. There is no second, independent copy to check it against. So verifying the bill usually means asking the provider to confirm the provider's own number.
Three things: evidence the verifier did not produce, cannot modify, and does not need permission to access. A dashboard the provider owns and controls meets none of the three, however well it is built. That is the gap, and it is structural, not a question of anyone acting in bad faith.
Because evidence and reconstruction are different things. A record committed before the invoice existed before the question, and the timestamp is part of it. Anything assembled after the question is a reconstruction, produced by the party being asked. Committed first means the proof predates the doubt.
A visible meter is a real improvement. But a dashboard is the black box showing you something: you still cannot see inside, and the number is still produced and held by one side. Visible is not the same as verified. Recordation adds the part a dashboard cannot: a shared record both sides can check.
Your data does. The contents of every record, what was consumed and how much, are never published. Either side can still check that a record is intact, but that check carries none of the underlying detail. Showing the contents to anyone beyond the two parties is the record holder's deliberate, revocable choice. Shared. Fixed. Private.
The record stays private, between the vendor and the customer. Its contents are never published. PacSpace holds them in order to run the service and for nothing else, and they are shown to anyone beyond the two parties only by the record holder's choice.
The customer is the verifier. They check the same committed record directly. Verification comes from the shared record itself, not from publishing anything.
No. The contents of your records are never published. What is recorded for verification is a fingerprint that reveals nothing about those contents, and showing the contents themselves to anyone beyond the two parties is the record holder's deliberate choice.
No. Nothing in your records is sold or shared. 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. PacSpace's revenue comes from recording capacity, not from your data.
No. PacSpace records, it does not decide. The record shows what was committed, and both sides read it. This is not about correctness. It is about transparency.
Neutrality is structural, not a matter of who pays. The record is produced the same way regardless of who is asking, reads the same for both sides, and PacSpace's revenue is decoupled from any outcome. Payment can corrupt discretion. It cannot corrupt a record that has no discretion in it.
No. We never audit, arbitrate, score, rank, or meter. We commit the record, and both sides read it.
The records survive. Proofs live on infrastructure outside any party's control, including ours, and checking a record doesn't require PacSpace to exist. Don't trust us; trust the math. The verification survives the company.
You control the cadence. Each record is a delta, one committed change in a customer's usage, and you choose how often to commit one. Lining commits up with how your invoices close is the natural choice. When you want closer to real time, commit deltas more often, down to hourly or smaller, and set the resolution per customer. Verification works the same at every cadence, so finer granularity is a feature you can offer, not a limitation.
No. Once committed, the record reads the same for both sides, every time. It is the one fixed reference you both return to, so a number cannot quietly drift between when it was recorded and when it is questioned.
No. PacSpace never sits between your product and your customers. Recording happens alongside your billing job, on your cadence. If PacSpace were unreachable, your product wouldn't notice and your billing run wouldn't stall; you commit the window when it's back.
Engineering time back and deals that move. Your team stops reconciling token counts against customer telemetry and ships product instead. Finance closes the books on schedule. Procurement reviews that used to stall on unverifiable usage clear, so larger contracts close faster. And every renewal opens from a record both sides already trust, instead of relitigating last quarter's invoices. One record turns billing from a recurring argument into a non-event.
Confidence in the bill, without the back-and-forth. They check it against the same record the provider used, on their own and in minutes, with no support ticket and no waiting on a reply. It is spend they can stand behind in their own reporting, and one less line item they have to take on faith. The invoice stops being something to brace for and becomes something they can simply confirm.
A monthly subscription with an included volume of verified deltas, and overage at your plan's per-delta rate. No percentage of your revenue, ever: pricing is per verified delta recorded, never per dollar moved. Talk to us for current plans.
On a normal day, almost nothing. Metering, rating, and invoicing keep running in the systems you already use. The one addition is the flush: on the cadence you choose, each customer's usage is committed to the record. That runs on its own once it is wired in; nobody on the billing team babysits it. The difference shows up on the days that used to hurt: close, and the day a customer questions an invoice.
Today that email starts a hunt. Engineers pull logs, finance rebuilds the month in a spreadsheet, and the customer runs their own tally in parallel. With recordation, the reply is one link. The customer's team opens the same record the invoice was built from and checks it against their own numbers. If something really is off, both sides can see which day it is off on, and the conversation starts from one specific committed delta instead of a disputed monthly total. Most questions end there, without a ticket ever reaching engineering.
What it looks like now, minus the scramble. Usage has been committing all month, so there is no end-of-month reconstruction. Before invoices go out, you lock the period, which freezes the window so the invoice references a record that can no longer move. Your dashboard shows which customers are ready to close and which still need something. Then the invoice goes out carrying its verification link.
They see a link, on the invoice or shared directly, that opens their record: what was committed, when, and the running balance for the period. Detail beyond the summary sits behind an access code you hand them. No account, no signup, no new system on their side. Their finance team can open the link mid-period too, and watch the month build instead of meeting the total for the first time on the invoice.
Most won't, most months, and the record still does its work. What changes behavior is that they could: a bill that arrives checkable is a different object from one that arrives take-it-or-leave-it, even when nobody clicks. The months nobody checks are the record quietly earning the benefit of the doubt. The month somebody does is the month it pays for itself.
You commit a correction. Records do not change once committed, so the fix is a new delta with its own stated reason, such as a credit that offsets the error. Both entries stay visible: the error, the correction, and why. That reads exactly the way your auditor wants it to read. What never happens is a number quietly changing after the fact, which is the thing that makes ordinary mistakes look like something worse.
One integration, wired once. When your metering closes a window, your system commits that customer's usage as a delta. It is designed to land as a small addition to an existing billing job, with no migration, no parallel billing system, and nothing to rip out. The docs walk through it end to end.
Start narrow. Pick one segment of customers, run recordation alongside your normal billing for a cycle or two, and put the verification link on those invoices. Nothing about the existing stack changes while you evaluate. When the record has earned its keep, widen it. Talk to us and we will walk through where it fits.
Companies charging customers for AI or agent activity on a meter the customer cannot check: inference tokens, model credits, GPU-hours, agent work. If the meter is growing faster than the trust underneath it, this is for you. The mechanism is the same everywhere; only the unit changes.
Inference tokens, model credits, and GPU-hours are all measured entirely inside the provider, so the customer has no way to run a parallel meter. And the spend is growing faster than anyone's comfort with taking it on faith: the bills are new, the numbers move, and nobody has years of trust to lean on. That is where a shared record helps most, and where we start. GPU compute is the same shape, metered by the provider and checkable by the FinOps team paying the bill.
Yes. Any metered product where one side produces the number and the other side has to accept it carries the same gap, and recordation works the same way. The difference is urgency: mature meters have flat disputes and patient humans, while AI and agent meters are growing into their questions fast. Most teams start where the meter is newest.
That is where it matters most. When software is the buyer, nobody is reading the bill, and manual reconciliation is impossible at machine speed. Agent-to-agent activity is recorded as it happens, checkable by both counterparties and their auditors. PacSpace never moves the money; it records what happened between the two agents, so neither side has to trust the other's log.
An open standard that lets software buy things. The web's original blueprint reserved error code 402, Payment Required, thirty years ago, and it sat unused because paying always needed a human. x402 finally puts it to work: a seller names a price, the buyer's software pays on the spot, and the thing arrives. No account, no checkout, no human. A vending machine for the internet, where the shopper is software and it shops thousands of times an hour.
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 only by the seller, in the seller's books, changeable by the seller. The rail proves the payment. We prove what it paid for. And the details stay private to the parties.
No. PacSpace works alongside x402 the way it works alongside your billing stack: additive, never a component. The record is useful wherever software buys metered things, whatever standard carries the payment. Rails change; the record requirement does not.
That is where a shared record stops being convenient and starts being necessary. One purchase, several sellers, each keeping its own version of what it contributed, and no shared account of the whole. With recordation, every party references the same record, so reconciliation becomes reference instead of negotiation.
Two private logs is the old problem at machine speed: my word against yours. Logs help you notice a difference; they cannot settle one, because each side wrote its own evidence. Settling needs one reference neither side can edit. That is what the record is.
Software does: automatically, on every exchange. That is the point. Verification finally moves at the same speed as the buying, and humans only look when a check fails. Delegation scales exactly as far as the record does.
Money moves at the speed of trust. A metered product grows as far as customers trust the meter, and trust taken on faith runs out exactly as the numbers get big. A record both sides can check removes that ceiling. Buyers spend more because sellers can be checked; sellers earn more because buyers can check. Nobody wins at the other's expense, which is why it works.
In the two places credit revenue stalls. Adoption: customers hesitate to scale spend on a meter they cannot see into, so growth slows exactly when the dollars start to matter. And automation: features that buy more credits automatically only get switched on, and left on, when the customer trusts the number that triggers them. The hours your team stops spending on billing questions are real, but they are the mechanism, not the value. The value is the meter being allowed to grow.
Bigger commitments, faster. Committed-spend deals and procurement reviews stall on unverifiable usage; a checkable meter clears them. The FinOps team paying your bill can stand behind the spend in their own reporting, which is what lets them approve more of it. And renewals open from a record both sides already trust, instead of relitigating last quarter.
In the budget. The gating question for every agent product is how much money a customer will let it spend, and people extend to software exactly as much spend as they can verify. A checkable record is what lets the limit rise. And when buying software chooses between sellers, a meter that can be checked is a criterion a machine can select on. The checkable seller gets chosen.
No. It saves real cost, the log pulls, the rebuilt months, the escalations, but that is the mechanism. The value is what the overhead was quietly holding back: meters trusted enough to grow, features trusted enough to automate, budgets trusted enough to raise. Cost relief is how it feels in week one. Growth is why it is still there in year three.
Correct, and nobody reads a thirty-line bill either. Reading was never the safeguard. Billing actually runs on reconstruction: when something feels wrong, a human rebuilds what happened from logs, exports, and email, and settles it over weeks. Volume does not create the problem; it removes the human with time to do the rebuilding. The record replaces reconstruction with reference. Settling a question becomes a lookup, at whatever speed the questions arrive.
You can build logging, and even a beautiful invoice. You cannot build neutrality, because your customer would still be trusting your system. The record has to live where neither party can revise it, and that cannot be inside either party. Neutrality is the one thing you cannot build for yourself.
Yes. We run our own vendor bills through it. Those records are committed and checkable today.
That asymmetry is real, and we name it rather than hide it. The provider writes, because the provider is the only party positioned to observe the usage. What changes is what writing does: the moment a record is committed, the provider cannot revise, regenerate, or selectively present it. Written by one side. Visible to both. Owned by neither. Neutrality is not about who writes. It is about who can change what was written, and the answer is nobody.
Nothing, and that is by design. We make claims fixed, not true. A fixed claim can be tested against the customer's own reality, and a provider whose committed numbers keep diverging builds a permanent, checkable history of exactly that. Ordinary databases forgive quiet revision; committed records make it visible. Transparency does the enforcing.
No, and the system does not assume it. Metered numbers drift apart for honest reasons: retries, batching, clock drift. Nobody has to be lying for two systems to disagree. The record exists so an honest disagreement can be settled by looking instead of arguing.
Helpful, and still one-sided. An export is produced by the same system that produced the invoice, and it can be regenerated to say something else next week. The customer is not checking your claim; they are re-reading it. A committed record is different in kind: fixed when it was written, readable by both sides, revisable by neither.
Keep them; they are genuinely useful. An audit trail inside the billing stack explains the charge: what changed, when, and why, from the provider’s own books. But it is still the provider’s account of itself, produced, held, and shown by the same side that sends the invoice, so the customer reads it on trust. A committed record answers a different question: not “can the provider explain this number” but “can either side check it without asking the other.” The two work together, and neither replaces the other. The platform’s trail explains. The record proves.
Audit rights are verification by permission: slow, adversarial, and invoked maybe once in a relationship. Even when the evidence exists, having to demand it routes the check back through the party being checked. The record is the audit right exercised continuously, by either side, with no lawyers and no meeting. Most audits end before they begin, because the answer was already checkable.
Everyone big in the flow is a participant: they run the rail, sell the infrastructure, or process the billing, and they are paid by its sides. A record held by a participant is that participant's word. This seat only works when it is held by a party with no other role in the transaction. That is not our marketing; it is the job description.
We will happily explain what the system guarantees and why: records committed at the time, checkable by either side without asking permission, revisable by no one, durable beyond us. How it is built is an engineering conversation we have with teams during integration. The mechanism is not the product, the same way an app's cloud provider is not the app. Judge the property; the property is checkable.
Auditors ask for evidence produced at the time, held where it could not be quietly revised, with corrections visible as corrections. That is what a committed record is. We do not replace your audit, and we never judge whether a number is right. We shorten the part where someone asks whether you can prove it.
Rules of that shape, including the record-keeping and logging obligations emerging around AI systems, keep describing the same artifact: a durable account of what a system did, kept where it cannot be rewritten. That is what recordation produces. To be plain: PacSpace is not a compliance product and does not make anyone compliant. It produces the record that compliance frameworks keep asking to see.
Support your finance team can stand behind. When agents spend, the invoices still land on company books, and the numbers still need evidence behind them. A record committed when the spend happened, checkable by your auditor without anyone's permission, is that evidence. It is the difference between agent spend that survives review and agent spend that gets frozen the first time someone asks.