Pre-state and post-state preservation
Capturing the relevant condition of a system before a meaningful event, while it is still the current state, and again after the event has settled.
In development
Program & system designProgram & system design.
AuditTrace Labs is developing a system-state preservation and forensic-context program: a design for preserving meaningful change, the evidence that supports it, and the context a reviewer needs to understand that change later.
Forensic review answers a question now. A preservation program is concerned with something harder — whether the question can still be answered when it is finally asked, by someone who was not present.
This page is deliberately high-level. It describes what is being designed, and the principles the design is held to. It does not describe how the mechanisms work.
What the program is designed to hold
- The relevant state before a meaningful change
- The change itself, scoped and authorized
- The state that remained afterward
- The evidence supporting each of those
- The context another reviewer would need later
The design question
One question sets the requirements.
Can another reviewer understand what happened weeks or months later without depending on the memory of the person who was there?
Every part of the program is measured against that question. It rules out designs that depend on a single surviving log, an undocumented assumption, or a conclusion nobody can retrace. It also sets an honest limit: where the source evidence was never preserved, no program recovers it.
Under active development
Eight areas of work, described at the level we can publish.
Each is an area of research and design. None of them is described here in implementation detail.
Long-horizon forensic review
Methods intended to keep evidence and system context understandable well past the immediate response window, where the available source evidence and chosen retention scope support it.
Evidence lineage and integrity
Provenance, chronology, acquisition conditions, manifests and documented gaps, treated as part of the evidence rather than as metadata around it.
Bounded system-state comparison
Recording the difference between two known states within an agreed boundary, so a change is compared rather than recalled.
Decision-grade context
Preserving why a change was made and what was known at the time, and keeping observed fact, derived conclusion, uncertainty and missing evidence distinct.
Human-gated AI and agent workflows
Software and AI may organize evidence, compare state and surface discrepancies. A person retains authority over scope and over any consequential conclusion.
Verifier-ready evidence packages
Assembling preserved material so an independent reviewer can check integrity and completeness themselves, where the underlying evidence supports it.
Authorized laboratory research
Controlled forensic and security research on owned, isolated, explicitly authorized systems, used to test what evidence reconstruction actually needs.
Design posture
Local-first and evidence-first, by construction.
Preservation is scoped around meaningful, authorized events and the evidence required to understand them. The objective is not indiscriminate monitoring, and not collection for its own sake.
Local-first means the design starts where the evidence already is, under the authority of whoever owns the system, rather than assuming everything should be shipped somewhere else first.
Evidence-first means the record comes before the claim. If the supporting material is thin, the program is designed to say so plainly rather than to present a confident summary the evidence cannot carry.
What the design excludes
- Continuous monitoring of people
- Person or behavior scoring
- Always-on endpoint capture
- Collection outside an authorized scope
Lineage without surveillance.
The program is built to explain what happened to a system, not to watch the people using it. Those are different problems, and conflating them produces worse evidence as well as worse ethics.
Program principles
The constraints the design is not allowed to break.
Human authority
A person decides scope, and a person reaches any consequential conclusion. Automation prepares the record; it does not rule on what the record means.
Explicit scope
Authorization, boundaries and protected assets are stated before work begins. Scope does not expand quietly during execution.
Evidence before claims
A statement is made when the supporting material exists. We prefer the weaker true statement over the stronger unsupported one.
Known versus unknown
Gaps, limitations and uncertainty are recorded as findings in their own right. An absence of evidence is documented, never filled in.
Today versus in development
What exists now and what is still being designed are labeled separately, on this page and in everything the program publishes.
Disclosure
Some of this is deliberately unpublished.
Detailed architecture, proprietary preservation methods, internal evidence rules, security controls and program mechanics are intentionally not published while development and validation continue.
That is a decision, not an omission. Preservation and forensic tooling is easier to defeat when its internal rules are public, and a method still under validation should not be described as though it were settled.
What is published instead is the shape of the work, the principles it is held to, and the limits we are willing to state in advance.
- Scope and intent: published
- Principles and limits: published
- Mechanics and internals: withheld
Future updates
This page is built to carry more as milestones close.
The sections below are the intended shape of future updates. They are published as work is completed and reviewed, not on a schedule.
- Milestones closed and reviewed
- Public documentation
- Technical papers
- Validation notes
- Limitations and known gaps
Nothing here is an announcement
No dates, availability, sign-up or eligibility exists for anything in that list, and none should be inferred from it. Each section appears only once the underlying work has been completed and reviewed by a person.
Status
Development proceeds in stages that can be closed and reviewed.
Research, laboratory validation, evidence workflow design and controlled program preparation are underway.
Each stage is bounded before it begins, and reviewed by a person before it is treated as settled. That pace is deliberate, and it is the reason this page describes design objectives rather than features.
Ask about the program
If your work depends on being able to reconstruct a system change later, describe the situation and what you need to understand. An inquiry does not guarantee acceptance, and work still in development is not offered here as a delivered capability. Please do not send credentials or sensitive evidence in an initial inquiry.