Systems investigation / Private lab
Legacy Protocol Restoration Evidence Lab
Legacy protocol/runtime restoration can turn into repeated guesses when the system is unclear. This lab keeps observations, theories, run findings, validation tiers, and verdicts separate enough to challenge.
I built a private C#/.NET and Python investigation workspace around runtime restoration, parser/diagnostic tooling, protocol-flow investigation, validation tiers, campaign verdicts, and provenance records.
Investigation lab
Legacy Protocol Restoration Evidence Lab
Ambiguous runtime behaviour is tracked through evidence-backed findings.
- Role
- Sole developer
- Focus
- Systems investigation and diagnostic tooling
- Maturity
- Private lab
- Access
- Private; local-only
- Technologies
- C#/.NET
- Python
- Last reviewed
- Jul 2026
The problem
What the project had to handle
The challenge is not only making one behaviour work. It is preserving why a theory seemed plausible, what was checked, what failed, and what should not be repeated.
The lab is private and local. Public writing focuses on method, tooling, and validation discipline rather than source, run artefacts, diagnostic captures, or sensitive protocol details.
Key decisions
The shape of the build
Reduce ambiguity into questions
Architectural unknowns become questions, theories, run findings, and verdicts instead of loose notes.
That keeps investigation work from repeating old assumptions or hiding failed paths.
Separate validation tiers
Findings can remain tentative, become reproduced results, or move into stronger proof categories.
The project can say what a result actually proved without overstating uncertain behaviour.
Keep artefacts private
Public material stays at methodology and tooling level while source, captures, and sensitive details remain local.
The work can demonstrate disciplined investigation without exposing material that should stay private.
How it works
End-to-end flow
The lab starts from architectural questions, then records theory deltas, parser findings, runtime observations, validation tiers, and campaign verdicts. C#/.NET restoration work and Python diagnostic tooling feed the evidence layer, while provenance records preserve what was checked and when.
01
Frame the unknown
Ambiguous behaviour is reduced into architectural questions and theories.
02
Run focused checks
Parser tooling, diagnostic runs, and runtime observations produce bounded findings.
03
Record the verdict
Findings become validation-tier records, theory deltas, or do-not-repeat paths.
What I implemented
The working surface
Runtime restoration
- Worked on C#/.NET restoration surfaces.
- Tracked runtime state gates and protocol-flow questions.
- Separated unresolved behaviour from validated findings.
Parser and diagnostics
- Built Python parser and diagnostic tooling.
- Used tooling outputs to support focused investigation runs.
- Kept sensitive diagnostic material private.
Evidence structure
- Recorded architectural questions, theory deltas, and campaign verdicts.
- Used validation tiers to distinguish hunches, observations, reproduced results, and stronger claims.
- Maintained provenance and do-not-repeat constraints.
Validation
Checks and evidence
Project checks passed
`scripts/validate-showcase`, `make doctor`, `make check`, and Finch verification passed for the lab.
Validation tiers documented
The project records distinguish static checks, focused tests, manual proof boundaries, and milestone bundles.
Diagnostic tooling present
The evidence packet supports C#/.NET restoration work and Python parser/diagnostic tooling.
Private boundary maintained
Public material is limited to methodology, validation discipline, parser/diagnostic tooling, and provenance patterns.
Current state
Private local investigation lab for legacy protocol/runtime restoration work.
The public page stays at methodology level: validation tiers, parser/diagnostic tooling, and provenance records.
Source, run artefacts, diagnostic captures, and sensitive protocol details remain private.