Documents

Threat Model and Security Posture

Tracepoint · A&R Strategic Solutions Version 1.0 · August 2026

Why this document exists

Tracepoint says its records are append-only and its packages are tamper-evident. Those words carry real weight in an audit context, so this document states precisely what they mean, precisely what they do not mean, and what an organization has to supply to close the difference.

We publish this because the alternative is worse. A tool that describes local records as "signed" and "immutable" invites a reviewer to rely on something that will not hold up when it is examined.

The trust boundary

Tracepoint runs entirely on one machine. There is no server, no database, and no network call. The workspace is a file the user holds. The application is HTML and JavaScript that runs in the user's browser.

Everything inside that machine is under the control of whoever controls the machine. That is the boundary, and it defines every answer below.

Inside the boundary: the workspace file, the application files, the system clock, the browser, the operating system, the local user account.

Outside the boundary: the organization's identity infrastructure, its file storage and backup, its PKI, any trusted timestamp source, and the reviewer who receives a package.

What we claim

1. Append-only within the application. The application offers no operation that edits or deletes a past audit-trail entry. Every mutation goes through one guarded path that checks the actor's role, validates the whole record graph, and then appends a numbered trail entry. Records are never edited in place; a change produces a new state and a new trail entry describing it. This holds within a running workspace. The one exception is a workspace file import: restoring a workspace from a file replaces the whole trail with the trail that file carries, because restoring a workspace means restoring its history. The trail rows are not chained to one another, so the trail cannot show that replacement by itself. A TraceSeal manifest taken before the import does show it. The sealed rows no longer re-derive afterwards, and the seal's verification names the rows that differ.

1. Byte-level integrity that anyone can re-derive. The export package carries a manifest of SHA-256 digests. Every record has a digest, the trail has a digest, and a root digest covers the whole set. The rules for producing those digests are printed inside the manifest itself: keys sorted, no insignificant whitespace, all characters above U+007F escaped so the canonical form is pure ASCII, records ordered by identifier, trail rows kept in trail order, numbers in shortest round-trip form. Anyone with any SHA-256 implementation can re-derive the same digests. Reproducing them does not require our software.

1. Complete source lineage. For imported findings, the package carries the original source row exactly as the file supplied it, plus every conversion applied to it, plus the SHA-256 of the source file itself.

1. Attestation, not signature. When a person records an action, Tracepoint stores the selected actor name, their role, their statement, and the time the device reported. The artifacts say, on their face, that this is a management attestation and not a digital signature under FAR 2.101.

What we do not claim

• We do not claim the named person is who they say they are.
• We do not claim the recorded time is the true time.
• We do not claim the workspace cannot be altered by someone with access to the machine.
• We do not claim the exported package is complete with respect to reality. It is complete with respect to the workspace it was built from.
• We do not claim the evidence attached is sufficient, authentic, or responsive. Tracepoint does not judge evidence.

Threats

For each threat: what an adversary can do, what Tracepoint detects, what it does not prevent, and what the organization must supply.

T1, Impersonation

Attack. A user selects or creates an actor profile bearing another person's name and records work as that person.

Detected. Nothing. The application has no way to distinguish a genuine profile from a fabricated one.

Not prevented. Entirely unprevented inside the boundary.

Compensating control. Identity has to come from outside. Two options: the organization signs the exported manifest with its own PKI, which binds a real credential to a specific set of bytes; or the workspace is operated on a machine where the local account is already tied to a CAC/PIV login and the organization is willing to accept that binding.

Disclosed on the artifact. Yes. Every package cover states that named actors are not authenticated unless external trust evidence is attached and validated.

T2, Clock manipulation

Attack. A user changes the machine's clock before recording an action, producing a trail entry with a false timestamp.

Detected. Partially. Trail entries carry a sequence number as well as a time, so the order of operations survives even if the times are wrong. A time that runs backwards relative to the sequence is visible to anyone reading the trail.

Not prevented. The absolute time cannot be trusted.

Compensating control. A trusted timestamp authority applied to the exported manifest. This is the standard remedy and it works cleanly here, because the manifest is a small, byte-deterministic artifact designed to be signed elsewhere.

Disclosed on the artifact. Yes. Every package states that device time is not trusted time.

T3, Deletion

Attack. A user deletes the workspace file, or clears the browser's local storage, and the record of work disappears.

Detected. Nothing, by the application. A deleted workspace leaves no trace inside the application because the application is the thing that was deleted.

Not prevented. Entirely unprevented.

Compensating control. Ordinary file custody: the workspace file placed on managed storage with backup and retention under the organization's records schedule, and packages exported at checkpoints and retained separately. A package that has already been exported and stored elsewhere is not affected by a later deletion.

Disclosed on the artifact. Yes. Every package states that the holder controls the local workspace file.

T4, Editing the workspace outside the application

Attack. A user opens the exported workspace file in a text editor, changes a record, and re-imports it.

Detected. Yes, if a package was exported before the change. The altered record produces a different digest, and the root digest changes with it. Anyone holding the earlier manifest can identify exactly which record moved.

Not detected. If no earlier package exists, there is nothing to compare against. A digest proves two things are the same or different; it cannot prove which one is original.

Compensating control. Export a package at meaningful checkpoints and store it outside the workstation. Detection depends entirely on having an earlier fixed point.

T5, Administrator or root-level tampering

Attack. Someone with administrative rights modifies the workspace, the application files, or the browser itself, and recomputes the digests so everything appears consistent.

Detected. Nothing, if the tampering is complete and internally consistent.

Not prevented. An adversary who controls the machine controls everything on it. No application running on that machine can defend against its own administrator.

Compensating control. This threat is out of scope for any local application and has to be answered organizationally: workstation hardening, privileged access management, and storing signed packages outside the workstation so an external copy exists.

Our position. We state this plainly rather than implying our hashing defeats it.

T6, Substituting the application

Attack. A modified copy of Tracepoint is installed that appears normal but writes different records or omits trail entries.

Detected. Nothing at runtime.

Compensating control. Every build publishes an integrity manifest alongside it. The manifest lists the SHA-256 of every file in the build, plus a single root digest covering the whole set, and it ships in the standard format so an organization can verify what it received with one command:

shasum -a 256 -c SHA256SUMS

The application is also served with a Content Security Policy that pins the hash of its one inline script. A modified script does not execute under the policy the build shipped with, and the build fails if the script and the pin fall out of step.

T7, Selective omission

Attack. A user exports a package covering only the findings that look favourable, and presents it as the complete picture.

Detected. Partially. The package states its own scope on the cover: how many findings, CAPs, populations, and evidence items it contains. A reviewer can see the count. What the reviewer cannot see from the package alone is whether the workspace held more.

Not prevented. A user may build a workspace containing only part of the population.

Compensating control. The population completeness feature exists for exactly this reason: a population record describes how a data set was extracted, by what method, with what control totals, so that completeness becomes a stated and checkable claim rather than an assumption. The application states in its limitations that population completeness may remain unverified, and that no application can know whether the source supplied every record.

T8, Evidence substitution

Attack. A user attaches a document that has been altered, or that does not actually support the corrective action it is filed against.

Detected. Alteration after attachment is detected. Tracepoint hashes the actual bytes of an ingested file with SHA-256 and carries both the hash and the bytes in the package, so the copy a reviewer receives can be checked against the hash recorded at ingestion.

Not detected. Whether the document was genuine in the first place, and whether it actually supports the claim. Tracepoint does not assess evidence sufficiency and says so.

Compensating control. Reviewer judgement, which is the correct place for this decision.

T9, Concurrent use and divergent copies

Attack. Not an attack so much as a failure mode. Two people work on copies of the same workspace and the copies diverge.

Current behaviour. Tracepoint is single-holder by design. One workspace file, one person at a time. There is no merge, no locking, and no conflict resolution, because there is no shared store to lock.

Practical handling. Work is divided by case or by component so that two people are not holding the same workspace. Each workspace exports its own package and the packages are assembled at the reviewing level.

Design boundary. One holder per workspace is a deliberate consequence of having no server, and the same choice is what makes the product deployable with no infrastructure and no authorization boundary. Teams scale by workspace: each case or component runs its own, and the packages assemble at the reviewing level.

T10, Data spill through the package

Attack. A package containing sensitive or classified material is distributed to someone not cleared for it.

Current behaviour. Tracepoint marks every package "UNMARKED, apply your organisation's handling marking before distribution". It does not classify, mark, or restrict content, and it does not scan for classified material.

Compensating control. The organization's own marking, handling, and review procedures. Tracepoint is not a cross-domain solution and must not be used as one. Because it never transmits anything, a package moves only when a person moves it, which keeps the decision with a human under existing procedures.

Role separation

Tracepoint defines six roles: remediation lead, CAP owner, evidence custodian, reviewer, leadership read-only, and external liaison. Every guarded action names the roles permitted to perform it, and an actor outside that set is refused with the reason stated.

Two points of honesty. First, role separation constrains what the application will do for a given profile; it does not constrain what a person can do, because the same person can create a second profile. It is a workflow control, not an access control. Second, the independence rule in sustainment testing is enforced in the data: a sustainment cycle whose reviewer equals its preparer is refused. That is a genuine structural check, and it is the kind of separation that survives review because it is visible in the record rather than asserted in a policy.

Backups, retention, and records

Tracepoint stores nothing outside the machine, so backup and retention are the organization's, using its existing tools. The workspace exports as a single file that can be copied, versioned, and backed up like any other document.

The package includes a records-handoff section for the organization's records schedule. Tracepoint states in its limitations that it is not the official agency repository unless formally designated, and that retention depends on external agency procedures. It is a working tool that produces artifacts for the systems of record, not a system of record itself.

Attack surface

Because there is no server, the usual surface is largely absent. There is no network listener, no API, no authentication endpoint, no session, no database, and no multi-tenant boundary. The application makes no outbound requests; a workstation with the network disabled runs it identically.

The surface that remains: the local machine, the browser, and the source files a user chooses to import. Import is the one place untrusted input enters. Imported files are parsed, never executed, and imported content is displayed as text rather than markup. Nothing is created from an import until a person reviews the preview and confirms it.

Verification performed

The claims in this document were checked against a real build rather than asserted from the source code:

• The production build was served under its own security headers and exercised end to end: the workspace loaded, the reconciliation ladder rendered, and both the full export package and the reviewer package were generated successfully under the policy.
• The integrity manifest is produced by the build itself, and the build fails if the Content Security Policy script pin no longer matches the file it pins.
• Every asset is emitted as a file rather than inlined, so both typefaces load under the shipped policy. Serving the production build under its own headers is a standing step in every release check.

What would change these answers

Three external additions materially strengthen the posture, in this order:

1. Organizational signature over the manifest. This is the highest-value single step. It converts a local attestation into something an agency's own PKI stands behind, and the manifest was designed for it.
2. A trusted timestamp on the manifest. Removes reliance on the workstation clock.
3. Custody of exported packages outside the workstation. Creates the earlier fixed point that makes tampering detectable.

None of the three requires a change to Tracepoint. All three are ordinary practices an organization already has the means to perform.

Summary

Tracepoint is a local application, and local applications cannot solve identity, time, or custody by themselves. What it can do is produce a record that is complete, ordered, attributed, disclosed, and byte-verifiable by anyone, and hand that record to the infrastructure that can solve the rest.

Every limitation described here is also printed inside every package the product produces. A reviewer does not have to read this document to learn them.