Become a proof partner

Any vendor whose product makes enforcement decisions about AI agents and wants those decisions to appear in the RepoOps accountability ledger as receipts, correlated to the agent session that triggered them. A vendor that emits spec-conformant events needs no adapter: RepoOps ingests conformant NDJSON as-is. Non-conformant formats need a small normalize adapter on the RepoOps side; two ship today (gitleaks for secret-leak findings, LiteLLM guardrails for gateway verdicts), and any spec-conformant tool works without one.

Events are newline-delimited JSON (NDJSON): one complete JSON object per line, UTF-8, no wrapping array. Every event carries v: 1. One event:

{
  "v": 1,
  "ts": "2026-07-16T09:12:03.120Z",
  "partner": "your-product",
  "category": "egress-policy",
  "event": "decision",
  "verdict": "blocked",
  "rule": { "id": "SSN", "action": "block" },
  "target": { "host": "api.anthropic.com", "toolHint": "claude-code" },
  "match": { "class": "ssn", "count": 1 },
  "processHint": { "pid": 4312, "exe": "node.exe" }
}

Required fields:

• v: spec version, always 1.
• ts: ISO 8601 date-time with an explicit zone, per your clock.
• partner: your id token, lowercase a-z 0-9 . _ -, max 64 chars.
• category: one of egress-policy, gateway-guardrail, ai-dlp, secret-leak, dependency-scan, runtime-sandbox, identity, egress-imds.
• event: decision (one enforcement decision), finding (a scan finding), verdict (a summary over a run), or activity (heartbeat-grade: you ran).
• verdict: passed, failed, blocked, redacted, or logged.

Optional fields:

• rule: { id, action? }. Your rule identifier and its configured action (block, redact, log, report).
• target: { host?, toolHint?, file? }. The destination host, your guess at the AI tool involved, or a repo-relative file path (a path, never a content excerpt).
• match: { class, count }. What matched, as a class token and a count only.
• processHint: { pid?, exe? }. Best-effort local process hint for session correlation. exe is a basename, never a command line.

• No matched content, ever. Events carry match classes and counts, never the matched text, the payload, the secret, the URL path, or any fragment of what was scanned. The reference validator rejects any field outside the schema (fail closed): an unknown field is the content-smuggling vector. RepoOps additionally applies write-time redaction at its event chokepoint as a backstop, but conformance means the content never leaves your product in the first place.
• Attested, not verified. Events are partner-attested claims. RepoOps records, chains, and correlates them; it never re-executes, verifies, or re-implements your control. Receipts render labeled with your partner id, as your claim.
• Unknown partners are accepted but labeled. Any partner id matching the grammar validates. Partners not on the RepoOps recognized list are ingested and rendered with an unrecognized marker, never hidden. Validation and recognition are deliberately separate: you can start emitting today.
• Honest-null everywhere. No partner installed: the ledger section renders nothing. A broken feed shows no signal, never stale or fabricated receipts.

1. Local NDJSON file tail

   Append events to a local NDJSON log file; the RepoOps dashboard tails it with cursor state, so a restart never re-reads what it already ingested. Zero integration code on your side.

2. Local HTTP push

   POST /api/partner-events/ingest?repo=<id> on the local RepoOps dashboard, one spec v1 event per request. Optional HMAC: when the operator sets REPOOPS_PARTNER_INGEST_SECRET, the request must carry x-repoops-signature: sha256=<HMAC-SHA256 hex of the raw body>. A non-conformant event is rejected with the precise reasons; nothing is written, nothing is chained.

3. Hosted webhook (future)

   A hosted HMAC webhook for cloud vendors is planned for a later phase. Emitting through either local transport today requires no change when it lands: same events, same spec.

One line per event. A secret scanner reporting a finding and then a clean run verdict:

{"v":1,"ts":"2026-07-16T10:02:11.000Z","partner":"gitleaks","category":"secret-leak","event":"finding","verdict":"failed","rule":{"id":"aws-access-key-id","action":"report"},"target":{"toolHint":"git"},"match":{"class":"secret","count":1}}
{"v":1,"ts":"2026-07-16T10:02:12.000Z","partner":"gitleaks","category":"secret-leak","event":"verdict","verdict":"passed","rule":{"id":"scan","action":"report"}}

Or pushed over the local HTTP transport:

curl -X POST "http://localhost:4000/api/partner-events/ingest?repo=my-repo" \
  -H "Content-Type: application/json" \
  -d '{"v":1,"ts":"2026-07-16T09:12:03.120Z","partner":"your-product","category":"egress-policy","event":"decision","verdict":"blocked","rule":{"id":"SSN","action":"block"},"match":{"class":"ssn","count":1}}'

The response echoes the receipt: the deterministic event id (the idempotency primitive, so a retry never double-writes), whether your partner id is on the recognized list, and the session correlation RepoOps stamped on the event.

The reference validator is lib/partners/spec.mjs in the RepoOps repository: validatePartnerEvent(obj) returns { ok, errors[] } with one precise reason per violation. The conformance kit at test/fixtures/partner-proof/ carries valid and malformed NDJSON fixtures. A conformant producer satisfies all of:

• every emitted line parses as one JSON object and validates ok: true;
• each malformed fixture would be rejected by your reading of the schema;
• no emitted field ever contains matched content. Spot-check: grep your output for anything your rules matched; zero hits.

The Partner receipts section of the accountability ledgergroups events by partner: verdict, rule id, target, match class and count, and when. Each partner's receipts ride their own hash sub-chain, re-verified on every read, so the section carries a live chain-verified marker. Session correlation joins each event to the live agent session that triggered it, with an honest confidence label, never inflated. Enforcement decisions also surface as attested control facets on FleetView.

Building an integration, want your partner id on the recognized list, or need the conformance kit? admin@repoops.ai. Spec questions and adapter requests welcome; the spec is designed so most vendors never need an adapter at all.