Following docs/new_predicate_guidelines.md, answering the preliminary questions before a registration PR. This proposes registering the OpenFab Generation Predicate, an existing, implemented predicate for AI/agent code-generation provenance.
Predicate type URI: https://open-fab.ai/attestation/generation/v0.1 (kept under its own domain, like SLSA Provenance)
Spec: https://open-fab.ai/attestation/generation/v0.1/
Reference repo (two implementations, conformance vectors): https://github.com/Open-fab-ai/openfab
What's your use case?
Recording how an artifact was generated by an AI/agent pipeline, bound to file digests in an in-toto Statement v1: which byte ranges were machine-generated vs human-written (generated[]: path, line range, sha256, author = ai | human), which model and agent identity (did:key) produced them, a sha256 fingerprint of the prompt (the text itself is deliberately excluded), the machine acceptance contract that gated the artifact (embedded as re-runnable checks, with a normative claimed-vs-observed distinction for verifiers), and cryptographic human sign-offs whose signatures each cover their own approval record. In short, an AI bill of materials for generated code. Issue #244 asks for exactly this ("which bits of the code were AI-assisted"); this predicate is a worked answer to it.
Why don't existing predicates cover this use case?
SLSA Provenance records how an artifact was built, not how its content was authored. Among the AI predicates currently proposed: the AI Change Provenance / Authorship / Review family (#601, #602, #603) records effective author and reviewer at change/pull-request granularity, which is complementary but cannot say which lines within a change are machine-generated, and carries no prompt binding or acceptance contract; AI Agent Action (#588) and AI Agent Decision (#591) record runtime tool invocations and decisions, not artifact authorship; eval-result (#575) records model evaluation verdicts. No existing or proposed predicate provides per-range human/AI attribution within files, prompt fingerprinting, or an embedded acceptance contract with a claimed/observed verification split.
What might the new predicate type look like?
It exists at revision 0.1.5 after five public review revisions. Fields: spec_ref, builder, agent (did, base, model, kernel-convention Assisted-by: id, tools), prompt_sha256, params, generated[] (per-range attribution, non-overlapping ranges enforced), materials[], acceptance_passed plus the embedded acceptance[] contract, timestamp, signoffs[]. The spec normatively defines its canonical encoding (RFC 8785 for its value domain), signature coverage including sign-off records, and verifier input handling (raw statement authoritative, duplicate member names refused). A registration PR would follow the template, and every example would be a complete real signed statement: four signed attestations (one per reference implementation, with and without sign-offs) are published with test keys at https://github.com/Open-fab-ai/openfab/tree/main/docs/vectors
What policy questions do you want to be able to answer?
- Did a human review and sign off on this machine-generated change, and can each approval be verified independently (N of M distinct keys)?
- Which parts of this file came from a model, which model, and under which agent identity?
- Was the same prompt used across artifacts (fingerprint correlation) without disclosing the prompt?
- Did the producer's acceptance contract pass, as a self-report, and separately: did it pass when this verifier re-executed it?
- Does the commit's
Assisted-by: trailer agree with the signed attestation (the declaration/evidence pairing)?
Evidence of use and interoperability (relevant to the tiers discussion in ITE PR #63): two independent reference implementations (Rust CLI and browser/WebCrypto) that cross-verify each other's signed vectors in CI, and a third-party conformance suite, probityai/agent-evidence-vectors (v0.15.0), that pins the predicate's golden vector and carries the four signed attestations as accept members with reject twins.
If maintainers think this is a fit, I will open the registration PR (spec/predicates/ doc per the template plus the README index line; protobuf to follow). Feedback on scope and on the relationship to #601-#603 is welcome.
Following docs/new_predicate_guidelines.md, answering the preliminary questions before a registration PR. This proposes registering the OpenFab Generation Predicate, an existing, implemented predicate for AI/agent code-generation provenance.
Predicate type URI:
https://open-fab.ai/attestation/generation/v0.1(kept under its own domain, like SLSA Provenance)Spec: https://open-fab.ai/attestation/generation/v0.1/
Reference repo (two implementations, conformance vectors): https://github.com/Open-fab-ai/openfab
What's your use case?
Recording how an artifact was generated by an AI/agent pipeline, bound to file digests in an in-toto Statement v1: which byte ranges were machine-generated vs human-written (
generated[]: path, line range, sha256, author =ai|human), which model and agent identity (did:key) produced them, a sha256 fingerprint of the prompt (the text itself is deliberately excluded), the machine acceptance contract that gated the artifact (embedded as re-runnable checks, with a normative claimed-vs-observed distinction for verifiers), and cryptographic human sign-offs whose signatures each cover their own approval record. In short, an AI bill of materials for generated code. Issue #244 asks for exactly this ("which bits of the code were AI-assisted"); this predicate is a worked answer to it.Why don't existing predicates cover this use case?
SLSA Provenance records how an artifact was built, not how its content was authored. Among the AI predicates currently proposed: the AI Change Provenance / Authorship / Review family (#601, #602, #603) records effective author and reviewer at change/pull-request granularity, which is complementary but cannot say which lines within a change are machine-generated, and carries no prompt binding or acceptance contract; AI Agent Action (#588) and AI Agent Decision (#591) record runtime tool invocations and decisions, not artifact authorship; eval-result (#575) records model evaluation verdicts. No existing or proposed predicate provides per-range human/AI attribution within files, prompt fingerprinting, or an embedded acceptance contract with a claimed/observed verification split.
What might the new predicate type look like?
It exists at revision 0.1.5 after five public review revisions. Fields:
spec_ref,builder,agent(did, base, model, kernel-conventionAssisted-by:id, tools),prompt_sha256,params,generated[](per-range attribution, non-overlapping ranges enforced),materials[],acceptance_passedplus the embeddedacceptance[]contract,timestamp,signoffs[]. The spec normatively defines its canonical encoding (RFC 8785 for its value domain), signature coverage including sign-off records, and verifier input handling (raw statement authoritative, duplicate member names refused). A registration PR would follow the template, and every example would be a complete real signed statement: four signed attestations (one per reference implementation, with and without sign-offs) are published with test keys at https://github.com/Open-fab-ai/openfab/tree/main/docs/vectorsWhat policy questions do you want to be able to answer?
Assisted-by:trailer agree with the signed attestation (the declaration/evidence pairing)?Evidence of use and interoperability (relevant to the tiers discussion in ITE PR #63): two independent reference implementations (Rust CLI and browser/WebCrypto) that cross-verify each other's signed vectors in CI, and a third-party conformance suite, probityai/agent-evidence-vectors (v0.15.0), that pins the predicate's golden vector and carries the four signed attestations as accept members with reject twins.
If maintainers think this is a fit, I will open the registration PR (spec/predicates/ doc per the template plus the README index line; protobuf to follow). Feedback on scope and on the relationship to #601-#603 is welcome.