Infrastructure Evidence Kit
Organize explicit infrastructure exports into a traceable assessment package, with collection coverage, linked findings and verifiable file integrity.
- My role
- Design & implementation
- Scope
- Offline evidence packaging tool
- Release
- v0.1.0
Validation scope
Offline packaging & verification
133 tests and eight CLI scenarios. CI on Python 3.11–3.13; local macOS validation. Complete example: 4/4 collected. No new infrastructure access.
Inside the work
How it works
Declare the assessment scope
Describe assets, evidence requirements, collection attempts and assessment time. Select explicit local UTF-8 exports.
Expose collection gaps
Use the latest declared attempt for each requirement. Report collected, missing, stale, failed or empty without falling back to an older success.
Link findings to original files
Associate manual observations with evidence IDs for the same asset. Preserve exact file bytes and show incomplete finding attachments.
Package and verify
Write JSON, CSV and Markdown with a final SHA-256 manifest. Verify changed, missing or extra files against that recorded package.
Decisions & trade-offs
Latest attempt takes precedenceA failed retry stays visible
A failed retry stays visible
A newer failed, missing or empty export must not be masked by an older successful record. All supplied records remain available for review.
The trade-off
A previously usable export may remain attached while the current requirement is marked incomplete.
Separate coverage from healthCollected means evidence is available
Collected means evidence is available
A current report can contain failed network checks. The historical lab example collects all three reports, including the deliberately failed phase.
The trade-off
The tool does not interpret configurations or verify the author’s finding, severity or recommendation.
Preserve a verifiable packageExact bytes and an unsigned manifest
Exact bytes and an unsigned manifest
Original files and artifact hashes support repeatable review. Fresh output directories preserve earlier runs; verification detects changed, missing and extra files.
The trade-off
Hashes are not authentication. Someone changing both files and manifest can make a consistent package; supplied content is not redacted.
Technologies by purpose
Python
Offline CLI without runtime dependencies. Linux and macOS filesystem support.
JSON assessment
Explicit inventory, requirements, attempts and manual findings.
CSV & Markdown
Collection coverage and linked engineering review.
SHA-256
File-byte integrity relative to the unsigned manifest.
GitHub Actions
Tests and eight executable scenarios on Python 3.11–3.13.
Scope & evidence
Published evidence
- Release v0.1.0
Published code, documentation and reproducible examples.
- Validation record
133 tests, eight scenarios and declared verification limits.
- CI test matrix
Successful Python 3.11, 3.12 and 3.13 jobs.
- Historical lab handoff
Three original public reports, without a new lab run.
- Design decisions
Latest-attempt precedence and package integrity.
Validation limits
- No automatic collection, network scan, configuration interpretation or infrastructure health/compliance certification.
- Findings and collector metadata are supplied by the author. No findings does not imply a clean assessment.
- The manifest is unsigned and files are copied without secret redaction. Native Windows is outside v0.1 support.
Test captures
Recorded evidence rendered as documents · not a product interface.
Enlarge Collection gaps made visible
The report identifies missing, stale and failed evidence. Synthetic example: 1 of 4 requirements has current evidence.
Source · 2026-10-29
Enlarge Modified evidence detected
Verification detects a deliberate change in a packaged file. Internal integrity uses hashes; the manifest is unsigned.
Source · 2026-10-29