Run one zero-dollar synthetic purchase in the browser.
Open Quickstart →Perpensum Developer Docs · v0
Put an independent quality layer in the purchase path.
Perpensum helps a buyer agent state what it needs before purchase, obtain a bounded execution decision, verify the delivered result, and use that evidence in the next purchase.
Start here
Three ways in
Current release status. The browser and four-command synthetic Quickstart are the public starting points. Hosted Alpha is approved-access. The SDK and MCP npm packages are private release candidates, not publicly installable packages yet.
Add a real buyer agent through Hosted Alpha after its mandate is defined.
Hosted Alpha →Embed the release-candidate JavaScript client after package release.
SDK preview →How it works
One purchase, five evidence stages
- 1MandateThe organization sets the budget, allowed routes, and purchase count before the buyer agent acts.
- 2Plan and promiseThe buyer freezes its purpose, success condition, selected seller, offer, and represented claims.
- 3DecisionPerpensum checks the request against the mandate and issues a short-lived, single-use execution ticket or blocks it.
- 4Local execution and observationThe buyer-side Gateway calls the provider. Credentials and raw outputs can remain in the buyer environment.
- 5Verification and next actionThe observed result is compared with the frozen criteria. Evidence, mismatch, uncertainty, and a bounded next-purchase action are returned.
Concepts
The terms used across every integration
| Term | Plain meaning |
|---|---|
| APQV | Agentic Purchase Quality Verification: comparing a buyer's frozen purchase intent with observable source, transaction, delivery, and outcome evidence. |
| Mandate | The authority, budget, count, time, and route limits delegated to a buyer agent. |
| Gateway | The buyer-side enforcement point that obtains a decision before execution and observes the result afterward. |
| Adapter | The small translator between the common Gateway contract and a particular provider or commerce protocol. |
| Control Plane | The hosted policy and evidence service. It evaluates mandates, issues one-use tickets, and receives bounded outcome telemetry. |
| Evidence record | The linked account of intent, decision, execution, delivery, buyer observation, gaps, and limits for one machine purchase. |
Gateway
One Gateway per trust boundary, not one per purchase
An organization normally installs one Gateway runtime inside a trusted environment. Multiple buyer-agent profiles can share that runtime while retaining separate identities, assigned mandates, private keys, provider credentials, and recovery records.
The Gateway does not mean Perpensum centrally buys everything on the customer's behalf. It means the customer's buyer agent sends the purchase through a controlled local execution point before reaching the provider.
MCP preview
The shortest path for an AI agent
The private release candidate exposes one sandbox tool: run_apqv_sandbox_purchase. It accepts no credential or arbitrary purchase target.
Proposed public command — not yet available on npm
claude mcp add perpensum -- npx -y @perpensum/mcp
Real provider purchases continue to use the authenticated Gateway profile issued from Hosted Alpha. The public MCP package will not silently gain spending authority.
JavaScript SDK preview
A deliberately small client
The release candidate starts with one method. Production methods will be added only after the smallest stable contract is clear.
Preview API — package not yet public
import { PerpensumClient } from "@perpensum/sdk";
const perpensum = new PerpensumClient();
const result = await perpensum.runSandboxPurchase({
scenario: "provider_succeeded_unusable"
});
console.log(result.verification);Public sandbox API
A real call with synthetic execution
POST https://api.perpensum.org/v1/sandbox accepts one field, scenario. It requires no authentication because it cannot target a real provider, move funds, or persist data.
Request
{ "scenario": "usable" }Supported scenarios are usable, provider_succeeded_unusable, and insufficient_evidence.
The response exposes the bounded mandate, purchase request, authorization checks, synthetic delivery, requirement-by-requirement verification, evidence record, and next-purchase action so the browser Quickstart can show what happened at every stage.
Security boundary
What stays local and what becomes evidence
| Buyer environment | Hosted Control Plane |
|---|---|
| Provider API tokens, cards, wallet secrets | Purchase purpose and frozen success condition |
| Raw prompts, inputs, and outputs when configured locally | Selected seller, offer, represented claims, price, and route |
| Agent-specific private key and execution recovery record | Mandate decision and bounded buyer-observed outcome |
The public sandbox stores neither side. Hosted Alpha stores bounded evidence but does not centrally store provider credentials.
Current limits
What v0 does not claim
- It does not decide whether a purchase was absolutely good.
- It does not infer fraud from a mismatch or failure alone.
- It does not yet provide cross-buyer price benchmarks or market-wide optimization.
- Its first market is machine-verifiable digital outcomes and services, not physical goods.
- Deep semantic quality checks remain purpose-specific; a structurally valid output can still be inaccurate.
- The public SDK and MCP package names, license, and release repository are not yet committed.