“You're wrong about neutrality.”
That is how the conversation opened. No preamble, no softening. It is a frank thing to say to a company whose entire premise is being a neutral verifier, and for a beat it lands like a challenge.
It was not a challenge. It was a gift. A claim that blunt usually has a real argument behind it, and a real argument is the thing we most want to hear, because it is the thing we can actually work with. So we asked them to keep going.
Here is the rest, worth quoting almost verbatim, because it is the cleanest version of an argument we hear in some form regularly:
“If only one side pays you, you can't be neutral. Either both sides pay equally, or no one pays, or the entity doing the verifying is too compromised to be trusted. And by the way, you are also too small to be a trusted entity in the first place.”
The argument is internally consistent. It is also wrong about PacSpace, but not in the way you would think. It is wrong because it is applying a test from one category of product to a different category of product. The test it reaches for is real, and it matters in the category it was built for. It just does not measure what it claims to measure when you point it at us.
This note is about that test. Where it came from. What it is actually good for. And why the cleanest counterexample to it sits inside a piece of infrastructure most enterprise software buyers already use and trust, even though it fails the test by every literal reading.
The Moody's reflex
When a buyer or partner hears “neutral verifier” for the first time, the immediate reflex is to ask who pays. The question is not naive. It is informed by a specific and important failure mode that the credit rating agencies modeled almost perfectly for the world to see in 2008.
Moody's. Standard and Poor's. Fitch. All paid by the issuers whose securities they rated. The structural conflict was visible from the beginning, and the structural failure was eventually catastrophic. The rating agencies were not corrupted by individual bad actors. They were corrupted by the architecture of who paid for what. The work product was a judgment, and the people who paid for the judgment had a stake in its outcome.
The Moody's test, distilled, is this: if the verifier is paid by one of the parties whose claim is being verified, the verifier's output is suspect. The defenses people reach for are predictable. Make both parties pay. Have neither party pay (regulator-funded, public utility). Rotate verifiers so no one party can lock in a relationship. Each of these is an attempt to remove payment as a contamination vector.
The reflex makes sense. It is the right reflex for the right category. It just is not the right reflex for PacSpace, and the reason takes a minute to unpack.
What you are paying for, not who is paying
The test that matters is not who pays. The test that matters is what the payment is buying.
Moody's was paid for a judgment. The judgment was Moody's discretion applied to the issuer's circumstances. Two analysts looking at the same bond could reach different conclusions, and that was not a defect of the process. That was the process. The whole point of a rating was that Moody's brought expertise and applied it to make a call that other parties would defer to. Discretion was the asset. The asset was for sale. Payment ran through the asset.
This is the structure that makes payment a corruption vector. When discretion is the product, the party paying for the product has an incentive to shape the discretion. The verifier has an incentive to take that shape, slowly, over time, in ways that may not look like corruption to the people inside the system. Everyone is acting in good faith. The architecture is still rotted.
Now consider a notary. A notary is also paid by one side. The person signing the document pays the notary's fee. The notary's office does not ask the other party to chip in. There is no controversy about this. There is also no failure mode visible in the public record where notaries have been corrupted at scale by the structural fact that the signer pays.
Why? Because a notary does not exercise discretion. A notary does not judge whether the contract is a good contract, whether the signer is making a wise decision, or whether the document being signed will hold up well. A notary verifies that a specific person was present and signed at a specific moment. That act produces a record that is fixed in place from that moment forward. The notary's value comes entirely from not being the signer. Self-notarization is not a thing in any legal system in the world, and it is not a thing for the same structural reason self-verification is not a thing in any verification architecture. The whole point of the notary is that they are not the party making the claim.
A notary's work product is not a judgment. It is a record without discretion. The signer pays the notary the same fee whether the document is wise or foolish, true or false, durable or doomed. Payment cannot corrupt the work product because there is no judgment to bend.
This is the category PacSpace is in. The vendor pays for the act of committing a claim. The act has no discretion in it. The verified record is the same record regardless of what the claim says, regardless of how the customer will eventually feel about it, regardless of whether the dispute that emerges later resolves in the vendor's favor or the customer's. We do not adjudicate the claim. We commit it. The payment is for the commit, not for a favorable outcome, because there is no favorable outcome to sell.
When people apply the Moody's test to PacSpace, they are assuming the work product is a judgment. It is not. The Moody's test and the PacSpace question belong to different categories, and almost every disagreement about our neutrality traces back to that one category error.
The case the skeptic did not know they were making
Here is where the conversation gets interesting. Because the skeptic who reaches for the Moody's test is usually working in a world where single-sided payment for vendor-produced records already exists and already works, and the canonical example sits in plain sight on every enterprise AWS bill.
Amazon Web Services produces the Cost and Usage Report. CUR. It is a granular, line-item record of what the customer consumed, what each unit cost, and how the numbers were rated and aggregated to produce the invoice. The customer reads it from an S3 bucket they own. AWS produces it. AWS controls it. The customer pays AWS for the cloud services, not separately for the CUR, but the cost of producing CUR is folded into the price of doing business with AWS. Single-sided payment. Single-sided production. Vendor-controlled record.
CUR is, by the literal letter of the Moody's test, not neutral. The party doing the verifying is also the party whose claim is being verified. There is no second source. There is no independent timestamp. There is no party between AWS and the customer whose job is to ensure that the CUR row reflects what actually happened. And yet enterprise customers accept CUR, reference it in disputes, build internal reconciliation tools that consume it, and treat it as the source of truth for what they consumed on AWS.
Why does this work? It works for three reasons that are worth naming, because together they explain what the Moody's reflex is actually pointing at.
It works because AWS produces CUR at a level of granularity that gives the customer the illusion of verification. Every API call, every gigabyte, every second of compute, broken out by resource ID, region, account, tag. The granularity is high enough that the customer feels they can spot manipulation if it were happening. This is a real defense in some sense and a structural mirage in another. A vendor who wanted to manipulate the report could manipulate it at the level of how the granularity is constructed. The customer is not actually verifying. The customer is observing in detail. The two are not the same.
It works because the customer has no alternative. AWS is the verifier of last resort for AWS spend. The customer cannot stand up a parallel meter inside AWS infrastructure, cannot rerun the rating engine, cannot independently confirm what their workload consumed. They can compare CUR to their own application telemetry, and many customers do, and the comparison surfaces exactly the kind of disagreements that motivated PacSpace's existence in the first place. The customer accepts CUR because the cost of not accepting it is higher than the cost of accepting it, not because CUR is structurally trustworthy.
It works because AWS is large enough that customers extend trust beyond what the architecture would otherwise warrant. This is the honest part, and it is worth saying plainly. The customer trusts CUR because AWS is too big to plausibly cheat at this scale, and too dependent on the long-term commercial relationship to risk it. This is institutional trust standing in for architectural trust. It is reasonable in the AWS case. It is also unique to AWS.
We described this arrangement in a recent conversation as large companies grading their own homework, and the phrase landed because it is recognizable. CUR is accepted self-attestation. It is what happens when the customer has accepted that the vendor is the verifier and has built a tolerance for the conflict because the alternative is worse. It is the status quo we exist to replace. It is also the clearest evidence that the “who pays” rule is not the load-bearing one. If that rule were the real test, CUR would fail it and enterprises would not rely on CUR. They do rely on it, every day, at scale. So the rule is catching something other than what makes a record trustworthy.
So the question is not “should single-sided payment for vendor-produced records be permitted.” That ship sailed at AWS scale. The question is what makes a record produced under single-sided payment actually trustworthy, instead of merely accepted.
The test that matters
The test that matters comes out of what the word verification has to mean to do any work.
Verification requires evidence the verifier did not produce, cannot modify, and does not need permission to access.
That sentence is analytic. It follows from what verification is, not from a design choice. If a record is produced by the party making the claim, can be changed by them afterward, and can only be read with their permission, then “verification” is not what is happening. Something else is happening, and it might be useful, but it is not verification.
There are exactly three contamination points in any verification architecture. Three places where the party being verified can otherwise contaminate the evidence. Production, modification, and access. Let me walk CUR and PacSpace through each.
CUR production. AWS produces the report. The claim-maker is the record-maker. This point fails the test.
CUR modification. AWS can change the historical CUR data. They have changed it in the past, sometimes for legitimate reasons such as resolving billing errors, sometimes for less defensible reasons such as restating historical pricing under new contracts. The customer cannot prevent this and cannot detect it without comparing against a parallel record they would have to maintain themselves. This point fails the test.
CUR access. The customer reads CUR from their own S3 bucket, which feels like neutral access until you remember that the bucket is provisioned through AWS, accessed through AWS-issued credentials, and the data inside it was placed there by AWS. The customer cannot access CUR without an AWS account in good standing. AWS controls the gating. This point fails the test, although less obviously than the first two.
Three of three contamination points are owned by the same party. The Moody's test misses this, because the Moody's test is asking who pays rather than who controls the evidence. The verification property catches it cleanly.
Now PacSpace.
Production. The vendor records the claim. PacSpace does not produce the data; the vendor does, because the vendor is the only party who can credibly observe events that happen inside their infrastructure. This point is the same as CUR. The claim-maker is the record-maker. The Moody's reflex is right to notice this, and naming it directly is the honest place to start.
Modification. The vendor cannot modify the record after it is committed. The act of recording publishes the claim to a destination the vendor no longer controls. The vendor still claims; the vendor no longer revises. This point is different from CUR. The contamination path is closed by architecture, not by policy.
Access. The customer reads the verified record without the vendor's permission. The verification path does not route back through the party being verified. This point is different from CUR. The contamination path is closed by architecture.
Two of the three points close. The one that does not close is the same point that does not close for CUR, and it is the point where the vendor is structurally the only party who can do the work in the first place. The customer cannot meter what happens inside the vendor's compute, and asking them to is not a solution. It is asking for something that does not exist.
What PacSpace adds, then, is not a removal of vendor production. It is closure of modification and access. The vendor still produces the claim because the vendor is the only party who can. The claim, once made, becomes evidence the vendor cannot revise and the customer can read without asking. The verification property is satisfied on the two points where satisfaction is architecturally possible, and the third point is handled differently than the first two. It is handled by the fact that we are not in the category the test was built for.
The commit, not the judgment
The vendor producing the record looks like a failure under the Moody's test, and looks like an honest gap under the verification property. It is neither, once you notice that PacSpace is not selling correctness in the first place.
This is not about correctness. It is about transparency.
A correctness product would have to close the production point. A correctness product is in the business of telling you whether the bill is right. To do that, it would need a record produced by someone other than the two parties involved. That is a different product. It is also a much harder product, possibly an impossible one, because in the usage-based world there is no neutral observer. The vendor's compute is the only place the events happened, and no third party gets to sit inside it.
PacSpace is not in the correctness business. We sell the property of being able to test the claim, not a judgment about whether the claim is true. The vendor produces the claim because the vendor is the only party who can. We make the claim non-revisable and freely readable. What the customer does with it after that is up to them. They compare it against their own reality. They surface divergence. They raise the questions that need to be raised. We never weigh in on who is right. We just make it possible to ask the question against a record nobody can move.
This is why the production point does not contaminate the work. The Moody's test catches payment-corrupted discretion, and the verification property catches producer-controlled evidence, but both tests assume the work product is a judgment about whether something is true. Our work product is a commit. The producer of the claim does not gain anything from producing the claim under our architecture that they did not already have. They already made the claim. What they lose, structurally, is the ability to walk it back later. That loss is what the customer gets.
There is a second-order effect here that is worth naming, because it is the part of the architecture most people miss on first read. Once claims are non-revisable, getting a number wrong gets expensive in a way it was not before. Today, a vendor whose numbers and the customer's expectations diverge can quietly adjust next month, restate historical numbers, or absorb the disagreement into a credit and move on. The divergence never leaves the vendor's side of the table. Under our architecture, the original number is in the record at the moment it was made. It cannot be smoothed over. It can be explained, corrected by adjustment going forward, or disputed against the verified record, but the original number is permanent and readable. The vendor's incentive structure changes the day they integrate.
This is the grounding force, and it works without us ever touching the data. We do not score what is coming in. We do not gate-keep. We do not audit. We commit. The act of committing creates a downstream pressure on the producer to be careful at the moment of production, because the moment passes and the record stays. A vendor whose record consistently fails to hold up against what their customers observe is failing permanently, in front of every customer it happened to, in a record the vendor cannot take back. Each customer reads only their own record, but the vendor knows every one of them holds one. The market will price that. It does not need PacSpace to price it.
What this means is that the system gets more accurate over time as a consequence of being transparent, not as a service we provide. We do not promise accuracy. We promise commitment. Accuracy is what happens when commitment meets a market that can read the record. The grounding force is the customer, reading their own verified record, and everyone the customer chooses to show it to: the auditor, the procurement team, the regulator who asks. The contents stay between the two parties; what anyone can check independently is the proof that the record hasn't been altered. A vendor's claims either hold together over time in front of the people they were made to, or they don't. We just keep the record honest. The market does the rest.
This is also why the size question stops being load-bearing. A correctness product would need to be large enough to be credible as a judge, because a small judge gets ignored. A commit product does not need to be credible as a judge, because it is not making judgments. It needs to be credible as a place where claims go and do not come back. The architecture handles the credibility. The math does not care how big we are.
Why “single side pays” is a feature
Once you see what payment is buying, the structure of who pays becomes obvious.
The vendor pays because the vendor is the party committing a claim. The vendor is paying for the commit. The commit is not a judgment, so payment cannot corrupt it. The vendor is also, not coincidentally, the party with the standing to integrate. The customer cannot install instrumentation inside the vendor's compute. The vendor can. Single-sided integration follows single-sided observation, and single-sided payment follows single-sided integration. The structure is not a compromise. It is what the architecture requires.
Asking both sides to pay would not improve neutrality. It would create a new problem. The customer would now have a financial relationship with PacSpace and a basis to ask why we did not catch a vendor underrepresenting usage. We would be drawn toward making judgments to justify the customer's payment. The product would drift toward auditing, which is a different category with a different failure mode and a different load-bearing claim. The Moody's test would start applying, because we would have started selling discretion.
Asking neither side to pay would not improve neutrality either. It would just mean the verification work was being funded by something other than the people who benefit from it. The economics of who pays for the verifier do not change the architectural fact of what the verifier produces. A regulator-funded verifier producing the same kind of record under the same kind of architecture would have the same structural neutrality and the same structural limits. The funding model is downstream of the architecture, not the other way around.
The point that earns its keep is this: payment can corrupt discretion. Payment cannot corrupt math. The math here is whether the record exists in a place the producer cannot reach. If yes, the record is verified. If no, it is not. Who paid for the commit is irrelevant to the answer.
The silent notary
So when the skeptic raised the Moody's test and then in the same breath said we were too small to be a trusted entity, the second concern is the one that deserved the longer answer, because the first concern resolves once the architecture is named.
We are too small to be a trusted entity in the Moody's sense. That is true. We are also not trying to be a trusted entity in the Moody's sense. We are trying to be the silent notary in an attestation that already happens every month. The vendor was always going to make the claim. The customer was always going to receive the invoice. PacSpace adds the property that the claim, once made, survives. The claim survives revision attempts. The claim survives the vendor's institutional preferences about what the record should show in retrospect. The claim survives PacSpace too. If we went away tomorrow, the verified records made before we went away would still be verifiable, because the verifiability is a property of the record, not a service we render.
That last point is the answer to the size question. To ask whether PacSpace is too small to be trusted is to ask what happens if PacSpace fails. The honest answer is that the math does not need us to continue existing. The proofs are published to infrastructure outside any party's control, and any third party with basic tooling could re-run a proof tomorrow. The verification survives the company. That is not a marketing claim. It is what the architecture is for.
You do not trust PacSpace. You trust the math. And the math is not for sale, in either direction.
What survives us
The two-line version of all of this is the one we use when the AWS comparison comes up, and it works as a take-home.
AWS solved billing transparency for AWS. PacSpace solves billing verification between two parties where neither is AWS.
The longer version is the one this note is about. The Moody's test is the right test for judgments. The verification property is the right test for records. When the work product is a record, the question of who pays is downstream of the question of who can modify and who can withhold. Once those two are closed, the payment question stops being interesting. It becomes what it actually is. A fee for an act, paid by the party with the standing to ask for the act. The same way you pay the notary.
The deeper version is this. The production point looks like a failure under both tests, and is neither, because PacSpace is not in the correctness business. We sell transparency. The vendor still produces the claim. We make the claim impossible to walk back and impossible to withhold. PacSpace does not score what is recorded. The record is readable by the parties who have to live with it, and those parties are the ones with the standing to act on what they find there. Over time, this changes what the producer can do at the moment of production. The system becomes more accurate as a property of the architecture, not as a service we render.
The Moody's reflex is good instinct. It pattern-matches to a real failure mode, and the pattern is reasonable as a first move. It just stops one test short. The second test is who can modify the record after it is made, and who can read it without asking permission. If the answer to both is “nobody,” then who paid for the commit is the wrong place to look for the contamination, because the contamination would not live there. And the question that usually comes next, “but the vendor is still the one producing the record,” has a clean answer. We are not selling a judgment about whether the vendor is right. We are selling a record the vendor cannot move and the customer can read. What gets done with that record is for the parties who have to live with it.
That is what makes single side pays a feature, not a bug. The other side does not have to pay because the other side already has what they need. Standing. Standing without payment. Standing without permission. Standing that survives us, and a record that grounds the producer toward being right over time, whether we are watching or not.