Note on filing: xai-org/x-algorithm has Issues, Discussions, Wiki, and external PR creation all disabled. This issue is filed here on the companion wrapper repo as the canonical public proposal so xAI maintainers (and anyone else interested in this pattern) can read and reference it. If xAI ever opens an issues channel upstream, we will copy this proposal there verbatim.
Open code does not bind a particular ranking result to a particular code/model/config/input. That makes external reproducibility and audit difficult, even when the source is fully published.
This proposes a minimal, opt-in audit hook that lets external systems (researchers, auditors, integrators) bind a ranking output to the exact code, artifacts, and inputs that produced it. No required signing, no policy engine, no network call.
Proposal
After ranking completes, the pipeline emits a structured event:
pub struct RankAuditEvent {
pub algorithm_commit: String, // git SHA of running code
pub model_artifacts: Vec<ArtifactRef>, // { path, sha256 } per model file
pub config_hash: String, // JCS-canonical SHA-256 of runtime config
pub input_commitment: String, // Merkle root over input features
pub output_root: String, // Merkle root over ranked output
pub output_top_n_optional: Option<TopNOpening>, // optional selective disclosure
pub timestamp: i64, // unix seconds
}Emission could be a single callback, an in-process channel, or a file write, whichever fits the existing extension points (the candidate pipeline's SideEffect stage is one obvious place).
The event is only as strong as the observer that emits it: signing and anchoring should happen in the trust domain appropriate to the audit use case (operator-internal monitoring, external researcher review, regulator-vetted attestation, etc).
Non-goals
- No required cryptographic signing (signing is left to external receipt emitters)
- No policy engine, no rule evaluation
- No external network dependency
- No specific receipt format mandated
The hook should be format-agnostic so external systems can wrap it however they want (DSSE, in-toto, signed JWS, plain JSON for non-audit use).
Worked example
This repo (VeritasActa/x-algorithm-receipts) demonstrates the pattern using the published Phoenix pipeline. It runs phoenix/run_pipeline.py, captures the four required hashes externally, and emits an Ed25519-signed receipt verifiable offline with @veritasacta/verify (Apache-2.0). The wrapper does not modify the upstream repo.
An in-tree hook in xai-org/x-algorithm would make the same pattern available without requiring users to instrument from outside. The current real-mode wrapper captures stdout/stderr digests as a proxy; an in-tree hook would expose the structured ranking output directly.
Why this is useful even without xAI adopting any specific receipt format
The hook makes external receipt emission practical without invasive instrumentation. Researchers studying recommender behaviour can verify that a captured output came from a specific code+config+input tuple. Independent integrators can produce DSA-style audit artifacts. Internal teams get a stable surface for monitoring/regression alerts. None of those use cases require xAI to sign anything or run any external code.
Scope of the ask
This is a proposal, not a PR. A PR would be premature without maintainer input on:
- Whether the candidate pipeline
SideEffect is the right hook point
- Whether the four-field event is sufficient or should be richer
- Whether emission should be sync, async, or buffered
- Whether xAI prefers a stdout/stderr emitter (low intrusion) or a direct in-process callback (higher fidelity)
Happy to draft a PR if a channel opens. Also happy to leave this as a reference proposal if the upstream prefers a different approach.
Caveat
This hook would let external systems bind outputs to specific code/model/config/input tuples. It would not prove anything about fairness, truthfulness, or social impact of the output. Those are different audit problems requiring different methods. The hook is one substrate for the auditable property, not a complete solution.
Filed by Tom Farley (@tom_farley), founder of ScopeBlind. The linked wrapper repo emits receipts in a format my company maintains; the hook proposal itself is format-neutral.
Open code does not bind a particular ranking result to a particular code/model/config/input. That makes external reproducibility and audit difficult, even when the source is fully published.
This proposes a minimal, opt-in audit hook that lets external systems (researchers, auditors, integrators) bind a ranking output to the exact code, artifacts, and inputs that produced it. No required signing, no policy engine, no network call.
Proposal
After ranking completes, the pipeline emits a structured event:
Emission could be a single callback, an in-process channel, or a file write, whichever fits the existing extension points (the candidate pipeline's
SideEffectstage is one obvious place).The event is only as strong as the observer that emits it: signing and anchoring should happen in the trust domain appropriate to the audit use case (operator-internal monitoring, external researcher review, regulator-vetted attestation, etc).
Non-goals
The hook should be format-agnostic so external systems can wrap it however they want (DSSE, in-toto, signed JWS, plain JSON for non-audit use).
Worked example
This repo (
VeritasActa/x-algorithm-receipts) demonstrates the pattern using the published Phoenix pipeline. It runsphoenix/run_pipeline.py, captures the four required hashes externally, and emits an Ed25519-signed receipt verifiable offline with@veritasacta/verify(Apache-2.0). The wrapper does not modify the upstream repo.An in-tree hook in
xai-org/x-algorithmwould make the same pattern available without requiring users to instrument from outside. The current real-mode wrapper captures stdout/stderr digests as a proxy; an in-tree hook would expose the structured ranking output directly.Why this is useful even without xAI adopting any specific receipt format
The hook makes external receipt emission practical without invasive instrumentation. Researchers studying recommender behaviour can verify that a captured output came from a specific code+config+input tuple. Independent integrators can produce DSA-style audit artifacts. Internal teams get a stable surface for monitoring/regression alerts. None of those use cases require xAI to sign anything or run any external code.
Scope of the ask
This is a proposal, not a PR. A PR would be premature without maintainer input on:
SideEffectis the right hook pointHappy to draft a PR if a channel opens. Also happy to leave this as a reference proposal if the upstream prefers a different approach.
Caveat
This hook would let external systems bind outputs to specific code/model/config/input tuples. It would not prove anything about fairness, truthfulness, or social impact of the output. Those are different audit problems requiring different methods. The hook is one substrate for the auditable property, not a complete solution.
Filed by Tom Farley (@tom_farley), founder of ScopeBlind. The linked wrapper repo emits receipts in a format my company maintains; the hook proposal itself is format-neutral.