Add EPI Recorder: TRACE Level 0 record-producer + WCM attestation-source

[mohdibrahimaiml]

Summary

Adds integrations/epilabs-epi-recorder/ for epi-recorder 4.4.3.

• TRACE: record-producer, trace_conformance_level: 0 (software-only log-import). L1/L2 are not claimed (TR-RTE-001, TR-RTE-004).
• WCM: attestation-source (no WCM conformance level; we do not verify a custody manifest).
• Digest from the Level 0 conformance run (iter_errors=0, origin.producer=epi-recorder/4.4.3): sha256:d17f305b7f3e9950614df5ae6810b86b111c6a9aa23c37c71cac5dd503da591f.

Verified tier requested

Please evaluate for Verified. Reproduction (released packages only):

pip install "epi-recorder==4.4.3" agentrust-trace agentrust-trace-tests
epi record --out demo.epi -- python -c "print('ok')"
epi export trace demo.epi --out demo.trace.json
trace-tests verify --record demo.trace.json --level 0

Also: tool_transcript.hash == sha256(.epi); tamper -> InvalidSignature.

Release artifacts: https://github.com/mohdibrahimaiml/epi-recorder/releases/tag/v4.4.3

Seal completeness (truncation through 4.4.1): https://github.com/mohdibrahimaiml/epi-recorder/blob/v4.4.3/docs/KNOWN_LIMITATIONS.md#historical-step-content-truncation-through-441

Marketplace catalog regenerated via python scripts/generate_marketplace_catalog.py on the original listing; this commit updates yaml/README/CI pin only.

Links checked

• https://github.com/mohdibrahimaiml/epi-recorder
• https://epilabs.org
• https://pypi.org/project/epi-recorder/
• https://pypi.org/project/agentrust-trace-tests/
• https://github.com/agentrust-io/trace-spec

[github-actions]

🔴 Contributor Check: HIGH

Check	Result
Profile	HIGH
Credential	LOW
Overall	HIGH

Automated check by AgenTrust Contributor Check.

[mohdibrahimaiml]

@imran-siddique — EPI Recorder 4.4.1 is tagged and on GitHub Releases. This PR is the TRACE Level 0 + WCM attestation-source listing. We are requesting the Verified tier; reproduction is in the PR body (epi-recorder==4.4.1, trace-tests verify --level 0). Digest sha256:8c84baf799f0c0e59c2878d4a2a6f94941dd7f73e6965009a10c54e313a78112.

[mohdibrahimaiml]

Updating this listing from 4.4.1 to 4.4.3. While auditing seal completeness we found that sealed step content was truncated at 2000 characters through 4.4.1 — artifacts sealed on those versions are not full transcripts. 4.4.3 seals full payloads, truncates only in the viewer, and records content_truncated in the manifest; verification fails if it is true and warns for pre-4.4.2 artifacts that lack the field. 4.4.2 was withdrawn before PyPI after a regression that broke signature verification for pre-4.4.1 seals. Both are documented in CHANGELOG and KNOWN_LIMITATIONS. Reproduction and Level 0 digest updated for 4.4.3.

[mohdibrahimaiml]

4.4.3 is now on PyPI; CI is green.

[imran-siddique]

Merging at the tier the metadata claims, which is community. The Verified request is a separate decision and I am not granting it here.

What I checked

• epi-recorder 4.4.3 is on PyPI, 41 releases, and the version you pin is present.
• The v4.4.3 release tag resolves.
• docs/KNOWN_LIMITATIONS.md at that tag resolves and does disclose the historical step-content truncation through 4.4.1.
• The conformance workflow follows this repository's existing convention (aeoess-aps-conformance.yml, comply54-conformance.yml and others), so a per-integration workflow here is expected rather than unusual.

What made this straightforward to merge

You under-claim on both axes and you say why. TRACE is record-producer at level 0 with L1 and L2 explicitly disclaimed by naming the codes that would fail (TR-RTE-001, TR-RTE-004), rather than left unstated. WCM is attestation-source with no conformance level, because you do not verify a custody manifest and you say so. Two claims a submitter could have quietly rounded up, rounded down instead.

Linking your own KNOWN_LIMITATIONS.md for a truncation defect in shipped versions of your own product, in the submission asking to be listed, is the strongest signal available that the rest of the claims were made the same way.

And tier: community in integration.yaml while requesting evaluation in the README is the right way round. A submission that wrote verified into its own metadata and asked for confirmation afterwards would be a different conversation.

On the Verified tier

Not deciding it in this merge, and not because of anything about the submission.

The bar here is a maintainer reproducing the claim, not a maintainer reading a reproduction. The catalog currently carries two verified entries, ramen-ai cMCP Adapter and SOVP, and both got there by someone running the thing. Granting a third on the strength of a well-written request would make the tier mean something different for you than it meant for them, which is unfair in both directions.

Your four steps are runnable against released packages only, which is exactly what makes it evaluable, and the digest and iter_errors=0 give something to compare against. I will pick it up as its own piece of work rather than as a footnote to a listing merge. Nothing further needed from you meanwhile.

[mohdibrahimaiml]

Correction on three details in this listing, found by re-running the reproduction from a clean environment against released packages only.

The digest is not reproducible and I should not have presented it as evidence. sha256:d17f305b… came from one local run. A .epi contains a creation timestamp, a random workflow UUID, and a freshly generated signing key, so every run produces a different artifact — three consecutive runs here gave 3dc71957…, 90a5d89e…, and d0f297b1…. Nothing a third party computes will match the number in the PR body.

The claims that do hold on every run: trace-tests verify --level 0 → PASS (8 checks, TR-SIG green, Ed25519 verified), iter_errors() → empty, and tool_transcript.hash == sha256(.epi) within the same run.

verify_record wording: a bare call raises ValueError about requiring a trusted key. allow_embedded_key=True is needed to reach InvalidSignature. Tampering does break the signature on iat, subject, and tool_transcript.hash — the README overstated the call signature.

KNOWN_LIMITATIONS anchor: the correct fragment is #historical-step-content-truncation-through-4-4-1. The one in the PR body returns 200 but lands at the top of the page.

Level 0 PASS, empty iter_errors, the transcript binding, and the conformance workflow on 3.11 and 3.12 all reproduce as written from a clean venv.