Apps · Developer integration
Add a PCOC with a coding agent
A PCOC is an identifier the maker's own device creates. It carries a cost in memory and time, so a new one is not free. Anyone can measure that cost. The measurement does not decide who gets in. That decision is the service's policy.
This is not an app, and it is not a download.
Point a coding agent at the specification, and at your own code. The specification is precise enough that an independent implementation can measure the same object as everyone else. The agent does the wiring. You read the diff. The specification is the contract. Where an SDK and the specification disagree, the specification wins.
Name a producer, a verifier, an admission gate, or a combination. If you do not name a side, the repository guide tells the agent to ask before it edits.
Devices
Making one holds about 256 MiB the whole time. It takes at least 18 Bitcoin blocks, typically around three hours or more, but it varies. Leave the device running and awake. A laptop that can spare that memory is the straightforward fit. The Linux and Android apps are the demonstrators.
A phone can make one. It is a poor fit when the system sleeps the app, kills it in the background, or cannot keep 256 MiB free. Checking one is the cheap part. It does not hold that memory.
The specification names a low-end laptop only as the machine used to measure a rate floor. That is not a list of allowed devices.
Create PCOCs
On the maker's device: create the key, hold the memory, and produce the object. An app control that makes one can say "Create a PCOC to secure this account".
Verify PCOCs
On a service: measure the object. The measurement and the policy stay separate. The record does not say pass or fail, and it does not decide who gets in.
Integrate admission
Apply your policy after the measurement. Accept, refuse, and revoke are the service's decision. The sign-in can sit beside email or the sign-in you already offer. The words for that button are "Continue with PCOC". It is another way in, not an account at a third party.
A service can take the sign-in quietly and finish the slow check in the background, so an honest person is not left waiting on a one-word screen. A Continue with PCOC button is spelled out in ai/admission-button.md. You still choose the policy numbers. The specification does not set them, and it does not set a deadline for how soon the object must be shown.
What you do
- Open your repository in the agent, or tell it the path.
- Name the side: a producer, a verifier, an admission gate, or a combination. Name the language if you know it.
- Paste the prompt. The agent proposes the smallest change.
- Read the diff before you keep it. Stop on keys, signatures, and anything that decides who gets in. You set those numbers.
- Run the check the agent shows you. The quickstart lines are on the SDK page.
The contract
The specification is the contract between implementations. The SDKs (Rust, C, Go, and Java) are a tested shortcut when the language matches. They are not required. Building straight from the specification is fine when they do not fit, as long as the objects still measure the same way.
The prompt
Paste this into the agent. You can hand it this whole page instead, and tell it to follow the prompt.
The detailed instructions the agent must follow are in the repository at ai/README.md.
You are integrating PCOC. Make the smallest change that delivers the capability the human names. Preserve existing changes; avoid unrelated edits.
If the side is not named, ask first: producer, verifier, admission gate, or a combination.
Clone https://github.com/groundinglab/pcoc fully. Read ai/README.md and follow its role map. Prefer a released SDK when one exists; discover the tag from the clone and the SDK page. Where an SDK and the specification disagree, follow the specification and report it.
Keep production, measurement, and admission separate. Do not hard-code policy values or invent fields or rules the specification does not define.
Run the applicable tests and conformance checks. Report actual results, files changed, and conflicts. Do not change key material, signature semantics, or path-validation rules without human confirmation; flag admission-policy changes for review.
Where it should read
The agent follows ai/README.md. That file names the documents for the side you asked for. Current tags and the pack pin are in sdk/SPEC_PIN.
- The specification, and in the repository spec/GUIDE.md plus Satoshi Hike Construction.
- SDKs, with the quickstarts.
- Integrate a producer, Verifier and policy, Integrate an admission gate, and the sign-in wire.
- The conformance pack, spec/conformance/pack. The manifest SHA-256 is in sdk/SPEC_PIN.
- Worked code: the desktop app, the Android demonstrator, and the admission gate. Policy levers live in policy/README.md, not in the specification.
What done looks like
A producer is done when an object it makes is measured by a verifier that followed the specification, including one that did not use your code.
A verifier is done when its record matches the reference shape and the conformance pack, and the record itself does not admit or refuse anyone.
A gate is done when that measurement stays separate from the policy file, and a person can see and change every lever. Show the conformance result, or the exact command that produces it.