At this level
dev.cocore.compute · 19- dev.cocore.compute.attestation record A snapshot of a provider machine's hardware and software state, signed by its Secure Enclave. Content-addressed: many receipts strong-ref the same attestation record until the underlying state changes (binary upgrade, OS update, key rotation).
- dev.cocore.compute.defs defs Shared type definitions for dev.cocore.compute.* records.
- dev.cocore.compute.dispute record An exchange-signed adjudication of a complaint about a settled receipt. Published in the exchange's repo. The exchange's DID is the only DID permitted to publish a record at this NSID for a given settlement; any record at this NSID outside the exchange's repo is invalid by construction. The dispute lifecycle is open->resolved (terminal); resolution carries the outcome the exchange has already enacted (e.g. a refund settlement) and a signed rationale. Verifiers reading a settlement see status=dis
- dev.cocore.compute.exchangeAttestation record An exchange's self-published statement of operating posture: software commit, public signing key fingerprint, fee policy in effect, audit posture. The provider/requester analog of `dev.cocore.compute.attestation` for the exchange role. Settlements MAY strong-ref the active attestation so verifiers can pin which exchange-software / signing-key combination produced the record.
- dev.cocore.compute.exchangePolicy record An exchange's published terms of service. Records every parameter that affects how this exchange computes settlements and maintains per-DID token balances: fee schedule, supported currencies, self-loop rules, processor identifiers, and the token-accounting parameters (onboarding grant, balance floor, weekly refresh, monthly patronage distribution, treasury identity). A settlement record strong-refs the active policy so verifiers can re-derive the payout numbers offline. Policies are immutable pe
- dev.cocore.compute.job record A request for computational work. Published by the requester in their own repo before the work runs, so the provider has something to commit a receipt against.
- dev.cocore.compute.latency query Network latency rollup derived purely from indexed receipts' signed `startedAt`/`completedAt` pairs — the last ≤100 per group (overall, per-provider, per-model). No side metrics store: the receipts are the source of truth, so the numbers cannot drift from them.
- dev.cocore.compute.listJobs query Indexed `dev.cocore.compute.job` records authored by a requester (capped at 500). `requester` is required; omitting it returns no jobs.
- dev.cocore.compute.listProviders query List every indexed `dev.cocore.compute.provider` record (capped at 100). Read-only cache over the firehose; the provider's PDS is authoritative.
- dev.cocore.compute.listReceipts query Indexed `dev.cocore.compute.receipt` records (capped at 200), optionally filtered by provider DID, requester DID, and/or job URI.
- dev.cocore.compute.listSettlements query Indexed `dev.cocore.compute.settlement` records (capped at 200), optionally filtered by the settled receipt URI and/or the requester DID (matched against the authorization URI prefix).
- dev.cocore.compute.modelActivity query Aggregate receipt activity per model and per time window. Walks the most-recent indexed receipts (capped at 5000), groups by `body.model`, and tallies requests + tokens across the hour/day/week/month windows, with per-provider breakdowns. The scan cap is reported back as `scanned`/`scanLimit`/`truncated` so consumers can tell an exact total from a lower bound; `oldestScannedAt` is the earliest receipt that contributed to any window.
- dev.cocore.compute.paymentAuthorization record A requester's signed authorization permitting a named exchange to charge them up to a ceiling for a specific job. Published in the requester's repo before any work runs. Settlement records strong-ref this authorization to prove consent.
- dev.cocore.compute.provider record A compute provider's public profile. One record per physical machine. The DID owning the record is the provider's billable identity; the same DID may own multiple provider records (one per machine).
- dev.cocore.compute.receipt record A signed receipt of a single completed compute job. Published by the provider in its own repo. Strong-refs the requester's job and the active attestation. Carries an additional Secure-Enclave-bound signature so it remains verifiable across PDS migrations.
- dev.cocore.compute.settlement record An exchange's signed proof of payment for a receipt. Published by the exchange in its own repo. Strong-refs both the receipt being settled and the requester's payment authorization, so the full chain is independently verifiable.
- dev.cocore.compute.termsAcceptance record A user's affirmative acceptance of an exchange's terms of service / privacy policy. Published on the user's PDS so the record is portable + auditable + survives the user disconnecting from any one exchange. Clients prompt for re-acceptance whenever the active exchange policy's `termsVersion` doesn't match the version on the user's most recent acceptance for that exchange.
- dev.cocore.compute.verifyReceipt query Verify an indexed receipt offline-equivalently: structural checks against its job + attestation, a P-256 ECDSA signature check of `enclaveSignature` against the attestation public key, lexicon-schema validation, and — when an MDA cert chain is present — a hardware-attestation check bound to the signing key. `trustLevel` rises to `hardware-attested` only when a valid Apple chain certifies the receipt-signing key.
- dev.cocore.compute.verifySettlement query Verify an indexed settlement against its receipt and the requester's payment authorization: confirms the settlement chain is internally consistent and signed by the settling repo. Returns the verification verdict plus any findings.