Evidence Types

Every CRA requirement needs evidence proving it’s met. Fleet categorizes evidence into four types based on how it’s collected.

The Four Types

Auto (56)

Fully automated — the scanner can determine pass/fail without human intervention.

Examples:

• TLS version detected in config → Pass/Fail
• MD5 usage in security context → Fail
• Lockfile presence → Pass
• Default password detected → Fail

These produce evidence automatically on every scan.

Semi (150)

Automated detection + review needed — the scanner finds a pattern, but a human or LLM must judge whether it satisfies the requirement.

Examples:

• Auth check detected → but is it sufficient? (LLM reviews)
• Rate limiting code found → but are the thresholds appropriate?
• Logging framework present → but are the right events logged?

Semi findings are needs_review until triaged manually or reviewed by the LLM layer.

Doc (187)

Documentation required — these requirements are about processes, policies, and organizational practices that can’t be detected from code.

Examples:

• “Does the manufacturer have an ENISA notification process?”
• “What is the support period commitment?”
• “Are there contracts with component vendors?”

Collected via the questionnaire engine or manual evidence upload.

Test (8)

Active testing required — these need results from penetration tests, fuzz testing, or hardware testing.

Examples:

• “Debug interfaces disabled in production firmware” (hardware test)
• “JTAG/SWD interfaces secured” (physical test)
• “Power-loss safe update verified” (test)

Upload test results via the evidence API.

Evidence by the Numbers

Type	Count	% of Catalog	Collection Method
Auto	56	14%	Scanner (fully automated)
Semi	150	37%	Scanner + LLM or manual review
Doc	187	47%	Questionnaire or document upload
Test	8	2%	Test result upload
Total	401	100%

Note

The scanner handles 51% of requirements (Auto + Semi). The remaining 49% need human input via questionnaires or document uploads. Using the LLM layer can automate much of the Semi evidence.

Evidence Record Structure

Every piece of evidence — regardless of type — follows the same structure:

{
  "requirement_id": "CRYPTO-01-R1",
  "evidence_type": "auto",
  "source": "scanner",
  "content": "The product uses AES-256-GCM for encryption (src/crypto.rs:45)...",
  "content_hash": "sha256:a1b2c3...",
  "commit_sha": "abc12345",
  "status": "draft",
  "created_at": "2026-04-03T12:00:00Z"
}

Key properties:

• Immutable: Records are append-only, never modified or deleted
• Hashed: SHA-256 hash for tamper detection
• Traceable: Linked to requirement ID, commit SHA, scan ID
• Timestamped: ISO 8601 creation time

The Evidence Pipeline

Code Change → CI Scan → Findings → Evidence Records → Technical Documentation
                                        ↓
                            Dashboard (gap analysis, vault)

Each CI run creates a new set of evidence records. Over time, this builds a continuous compliance history — exactly what market surveillance authorities look for.