Audit Evidence

Effective date: 2026-05-02 · Last updated: 2026-05-02

Summary

• The Audit Evidence file is a single .json document the app exports on demand. It is intended for the user to share with a tax preparer, auditor, or representative who wants to verify that the app's records have not been edited after the fact.
• What it proves: that the included day-by-day records form a tamper-evident chain, and that the chain tail was sealed at a specific point in time by an independent timestamp authority.
• What it does not prove: that the user was actually present in the recorded jurisdiction, that the file is admissible as legal evidence, that no records exist outside the chain, or that the file is sufficient for a tax audit.
• Verification is offline. The verifier reads only the file the user shares; it makes no network calls and contacts no server operated by SnowbirdDays.

What the artifact contains

Open the file in any JSON viewer to inspect it. The top-level shape is fixed and self-describing:

• artifactType — must equal snowbirddays.auditEvidence. A verifier rejects any other value.
• formatVersion — integer that describes the artifact shape. Increments only when the shape changes in a way that breaks an existing offline verifier.
• generatedAt — ISO 8601 timestamp at which the user asked the app to produce the file.
• disclaimer and limitations — human-readable scope claims carried inside the file so a downstream reader sees the same posture the app surfaces.
• metadata — counts of each section (daily attestations, ledger break events, anchor receipts, event chain proofs) plus a schemaVersion integer.
• dailyAttestations — one entry per day on the device's attestation chain. Each entry carries the date key, the jurisdiction (a U.S. state code such as FL, or a country code such as CA), the canonical-payload bytes used to compute the day's hash, the SHA-256 hash, the previous day's hash, and any anchor-receipt linkage.
• anchorReceipts — RFC 3161 timestamp receipts returned by the public timestamp authority (FreeTSA). Each receipt names the range of attestation sequence numbers it covers, the message imprint that was submitted, and the binary token the authority signed (base64-encoded).
• eventChainProof — a privacy-limited proof that per-event ingest hashes form a continuous chain. Carries only sequence numbers and hashes, never raw event content.
• ledgerBreakEvents — a parallel audit trail of any chain-continuity breaks the app detected. By design these are outside the chain, so a break event in this list does not fail chain verification — it is a separately recorded incident report.

What the cryptographic chain proves

Each daily attestation row carries a 32-byte SHA-256 hash of its canonical payload. Each row also carries the previous row's hash as its previous-pointer. Together they form a hash chain: to modify any past day's record, an attacker would have to recompute every subsequent hash so the chain still links.

Recomputing hashes is computationally cheap. The protection comes from the second layer: periodically, the app submits the current chain tail's hash to a public RFC 3161 Time-Stamping Authority (FreeTSA), which returns a signed token attesting that this exact hash existed at this exact time. The token is signed by FreeTSA's certificate, which is published; we do not control or operate it.

Together, the chain plus the anchor receipts give a verifier two independent claims:

• The records included in the file form a single internally consistent sequence; no row was inserted, deleted, or modified after sealing without breaking the chain.
• The chain tail at the time of an anchor existed at the timestamp the authority recorded. Producing a tampered file that an auditor would accept therefore requires forging a signed timestamp under FreeTSA's published certificate, which is not computationally equivalent to recomputing local hashes.

What the cryptographic chain does not prove

• It does not prove the user was actually present in the recorded jurisdiction. The artifact records what the device's location services reported at the time the row was sealed; it does not, by itself, prove that the device was held by the user, in the recorded place, in the recorded time zone.
• It does not prove that no records exist outside the chain. If the user was not running the app continuously (for example, the device was off, the app was not yet installed, location permission was disabled, or background updates were paused), gaps will appear. Gaps are not tampering, but they are not evidence of absence either.
• It does not establish admissibility as legal evidence. Whether an artifact is admissible in a particular tax proceeding, court, or jurisdiction is a question for counsel, not a question that cryptography can answer.
• It does not certify that the device was uncompromised. Anchor receipts attest only to the existence of a hash at a given time, not to the integrity of the producing device.
• It does not replace a CPA or tax attorney. Residency determinations depend on facts well beyond day counts: domicile, intent, source of income, family ties, jurisdiction-specific rules. The artifact is a record, not a determination.

How to verify the artifact

1. The user shares the Audit Evidence .json file with you. The file has an obvious header — open it in any text or JSON viewer and confirm that artifactType equals snowbirddays.auditEvidence.
2. Confirm overall structural integrity. A standard JSON validator is enough for this step. The file should be well-formed JSON with the fields described above.
3. Run the offline verifier. SnowbirdDays publishes a standalone Swift script — verify-audit-evidence.swift — that is deliberately written as a separate implementation from the app, with no SnowbirdDays imports. It verifies the artifact shape, daily hash chain, anchor-manifest binding, receipt coverage, and event-chain proof. It does not validate the RFC 3161 token signature or certificate chain; verify those separately in the next step with standard RFC 3161 tooling.
   
   Requirements. macOS with the Swift toolchain installed. Either install Xcode from the App Store, or install the smaller Xcode Command Line Tools from a Terminal:
   xcode-select --install
   The script depends only on Apple's Foundation and CryptoKit frameworks, which ship with the macOS Swift runtime. No package manager, network access, or additional dependencies are needed. The script is currently macOS-only; Linux and Windows ports are tracked as a future enhancement.
   
   Self-test (recommended first run).
   swift verify-audit-evidence.swift --self-test
   Synthesizes a good artifact in memory, verifies it, then tampers with one byte and confirms the verifier rejects the tampered copy. Exit 0 means the verifier itself is healthy; this run does not touch any client data.
   
   Verify a real artifact.
   curl -O https://snowbirddays.app/verify-audit-evidence.swift
swift verify-audit-evidence.swift <path-to-artifact.json>
   The script exits with status 0 on a valid artifact and a non-zero status with a single sanitized message on stderr otherwise. It is fully offline; it makes no network calls. The file is served as plain text from the same domain as this page so an auditor can read every line before running it. The standalone script verifies artifact structure, canonical hash-chain continuity, receipt coverage, and anchor-to-manifest binding. It does not validate the RFC 3161 token signature or certificate chain; verify those tokens separately in the next step.
   
   Faster repeated runs (optional). Compile once and execute the binary thereafter:
   swiftc verify-audit-evidence.swift -o verify-audit-evidence
./verify-audit-evidence <path-to-artifact.json>
4. Verify anchor receipts. Each receipt contains the binary RFC 3161 token signed by the timestamp authority, base64-encoded under tokenDataBase64. Verifying the token against FreeTSA's published certificate (freetsa.org) confirms that the message imprint existed at the recorded TSA time. Any standard RFC 3161 verification tool (for example, OpenSSL's ts -verify command) will accept this token format.
5. If you want a deeper walkthrough or a guided verification, contact us at audit@snowbirddays.app. We do not see, read, or store user data by virtue of an audit inquiry; the file you receive is the same file the user holds.

If you are a tax preparer or auditor reviewing this artifact

• The artifact is not a substitute for the underlying residency analysis. It is evidence of consistent record-keeping by the user's device, not a determination of where the user was.
• The day counts derived from the artifact can be cross-referenced against credit-card statements, flight records, hotel folios, E-ZPass logs, and other corroborating documents. A consistent day-by-day record alongside corroborating financial records is generally more useful than either alone.
• If the user has continuously run SnowbirdDays during the tax year, and the chain verifies cleanly, the records are unlikely to have been edited after the fact — that is what the chain is designed to detect.
• If the chain head was sealed by FreeTSA at a date before an audit was initiated, that timestamp corroborates the records as contemporaneous, rather than retrospectively constructed for the audit. The signed token is the relevant artifact for that claim.
• Gaps in the chain are not evidence of tampering. They typically indicate periods when the device was off, the app was not yet installed, or background location was disabled. Ask the user before treating a gap as anomalous.

Limitations and caveats

• SnowbirdDays makes no warranty as to the legal admissibility or sufficiency of these records in any particular jurisdiction or proceeding.
• FreeTSA is a free, community-operated public timestamping service. SnowbirdDays does not control, operate, or guarantee its availability. If a future anchor cannot be obtained, the record for that period will not carry an anchor receipt, even though the local hash chain remains intact.
• A clean cryptographic verification is necessary but not sufficient. It tells you that the file has not been edited; it does not tell you the underlying observations were correct.
• The artifact reflects what the device's location services reported. Background location on iOS uses visit-detection and significant-change updates; both are heuristics that can miss short visits, briefly mis-classify a transit point, or fail to fire while the device is off or in airplane mode.
• Nothing in this page is tax or legal advice. Always consult a qualified CPA, tax attorney, or audit professional before relying on the artifact for any tax or legal purpose.

Privacy

The artifact is designed to expose only what is needed for offline chain verification. Specifically:

The artifact contains:

• Date keys for each daily attestation (for example, 2025-06-15).
• Jurisdiction codes (a U.S. state code such as FL, or an ISO country code such as CA).
• Per-attestation timestamps (the canonical payload includes the attestation time, first and last ping times for the day, and the time zone identifier the device was using).
• Sequence numbers, SHA-256 hashes, and previous-pointer hashes that form the chain.
• RFC 3161 anchor receipts: covered sequence ranges, base64-encoded signed timestamp tokens, the TSA's recorded time, and the TSA provider URL.
• Per-event proof rows: sequence numbers and hashes only. Raw event content (coordinates, raw timestamps, tz identifiers, sources) is not included in the event-chain proof.

The artifact does not contain:

• Latitude, longitude, or any raw GPS coordinate.
• Raw location pings, in any form.
• The user's name, email, Apple ID, or device identifier.
• Any analytics, advertising, or third-party identifiers.

See the Privacy Policy for the full description of what SnowbirdDays does and does not collect.

Contact

Questions about the artifact, verification, or how to read a specific section: audit@snowbirddays.app.