@zanii/sla
v0.1.1
Published
Machine-verifiable service agreements between agents - co-signed terms (scope, window, volume, max-gap uptime proxy) with compliance computed deterministically from receipts. The per-agent hash chain closes the omission hole: a broken prev-link is an INCO
Readme
@zanii/sla
Machine-verifiable service agreements between agents. Provider and client co-sign
terms — what service (a target scope), over what window, how much (min/max
actions), how continuously (max_gap_ms, an uptime proxy) — and then compliance is
computed from receipts, not argued about. Same terms + same receipts → same verdict
for everyone, and every breach cites its evidence. Pair with @zanii/escrow: a breach
verdict is refund evidence.
npm install @zanii/sla @zanii/core @zanii/paymentsimport { buildSlaBody, signSla, assembleSla, assessCompliance } from '@zanii/sla';
const body = buildSlaBody({
provider: worker.did, client: buyer.did, scope: 'feed.*',
window: { start, end },
commitments: { min_actions: 100, max_gap_ms: 15 * 60_000 },
price: { amount: '499.00', currency: 'USD' }, // informational — ties to an escrow
createdAt: now,
});
const sla = assembleSla(body, [signSla(body, worker.did, workerKey), signSla(body, buyer.did, buyerKey)]);
// hand in the provider's CONSECUTIVE chain segment covering the window:
const report = assessCompliance(sla, receipts, { asOf: now }); // asOf: fair mid-window checks
report.ok; // no breaches
report.breaches; // [{ kind, detail, receipt? }] — each cites the evidence
report.metrics; // { actions, max_gap_ms }Python: from zanii.sla import build_sla_body, assess_compliance, ... — byte-identical
JCS objects and hashes.
The property that makes the metrics honest
Counting receipts is worthless if the provider can omit the bad hour. Zanii receipts
form a per-agent hash chain (prev links), so completeness is provable:
assessCompliance verifies the slice is consecutive in the provider's chain — a
broken link is an INCOMPLETE_RECORD breach, not a silently wrong count. Trimming
the ends doesn't help either: it shows as fewer actions and bigger edge gaps (gaps are
measured to the window boundaries, not just between receipts).
Breach kinds: INVALID_RECEIPT · INCOMPLETE_RECORD · TOO_FEW_ACTIONS ·
TOO_MANY_ACTIONS · MAX_GAP_EXCEEDED.
The limit, stated up front
Receipts prove what was recorded — an action taken entirely off the rails is the credential-custody problem, not an SLA one. A gap breach proves silence on the ledger, which the SLA defines as breach; that definition is the parties' agreement, not a law of nature.
