Data Integrity
Data integrity is a foundational requirement across regulated industries. The FDA, WHO, and PIC/S all use the ALCOA+ framework to define what constitutes reliable data. This page documents how SealDoc satisfies each ALCOA+ attribute.
ALCOA+ Mapping
ALCOA+ stands for Attributable, Legible, Contemporaneous, Original, Accurate — plus Complete, Consistent, Enduring, and Available.
| ALCOA+ Attribute | Definition | SealDoc Implementation |
|---|---|---|
| Attributable | Who performed the action and when? | Every audit entry records the Jira account ID, display name, and UTC timestamp. The signer's identity is verified through the Jira session (Atlassian-managed authentication) plus PIN verification. The audit trail cannot be modified after the fact. |
| Legible | Can the data be read and understood? | Audit entries are stored as structured records with clear field names (action, user, timestamp, details, content hash). Entries can be viewed in the project page UI, exported as CSV for spreadsheet analysis, or exported as PDF for formatted reports. |
| Contemporaneous | Was the data recorded at the time of the activity? | Audit entries are created synchronously during each action (sign, approve, reject, revoke, configure). The timestamp is generated server-side by the Forge runtime clock (UTC) at the moment the action occurs. Entries cannot be backdated. Note: there is no independent time stamping authority (TSA) — the timestamp source is the Atlassian-managed Forge runtime clock. |
| Original | Is this the first recording of the data? | The audit trail is insert-only at the application layer — SealDoc never issues UPDATE or DELETE statements on audit entries. The hash chain ensures that the original sequence of entries is preserved — any insertion, deletion, or modification breaks the chain and is detectable via chain validation. |
| Accurate | Is the data correct and free from errors? | Content hashes (SHA-256) capture the state of the document at signing time. The hash is computed from summary, description, status, priority, attachment metadata (filenames and sizes), and safety classification. Attachment file content is not hashed due to Forge runtime constraints. If any included field is altered after signing, the hash mismatch proves the change. |
| Complete | Is all data present, including any modifications? | Every action is logged: signatures, approvals, rejections, revocations, classification changes, configuration changes, PIN lockouts, GDPR erasures, and chain seal checkpoints. No action bypasses the audit trail. Gap detection identifies missing entries. |
| Consistent | Is the data recorded in the same way across the system? | All audit entries use the same schema (entry ID, document key, action, user, timestamp, details, content hash, previous hash, entry hash). The same inputs always produce the same hash. |
| Enduring | Will the data be preserved for the required period? | Audit entries are stored in Forge SQL with configurable retention. Default retention is indefinite. Entries within the retention period cannot be deleted. Atlassian Forge infrastructure provides storage durability. Periodic CSV/PDF exports provide offline copies. |
| Available | Can the data be accessed when needed? | The audit trail is accessible from the project page and admin page at any time. Filtering by document, action, user, and date range enables targeted retrieval. CSV and PDF export allow offline access and sharing with auditors. |
Tamper Detection Architecture
SealDoc uses a two-layer tamper detection architecture:
Layer 1: Hash Chain
Every audit entry includes a SHA-256 hash of its fields and a reference to the previous entry's hash, creating a linked chain. If any entry is modified, inserted, or deleted:
- The entry's recomputed hash will not match its stored hash (detects modification).
- The next entry's
previous_hashwill not match the modified entry's hash (detects modification and insertion). - A gap in entry sequence numbers is detected (detects deletion).
Layer 2: HMAC Chain Sealing
Periodically, the entire chain is sealed with an HMAC-SHA256 using an app-managed secret key. This provides a second, independent integrity check:
- Even if an attacker recomputes the hash chain with consistent hashes, they cannot forge a valid HMAC seal without the secret key.
- The HMAC key is stored in Forge Storage and is not accessible to users or administrators.
- Sealing occurs after every write operation and on an hourly schedule.
Independent Verification
The audit trail can be independently verified:
- Built-in validation — the chain validation tool on the project page checks hash continuity, gap detection, HMAC verification, and entry integrity.
- Offline verification — export the audit trail as CSV. The export includes hash chain data (entry hash and previous entry hash) for every audit entry. An independent tool can recompute each entry's hash and verify that the previous entry hash matches the preceding entry, confirming chain integrity.
Content Integrity
Beyond the audit trail, SealDoc ensures the integrity of signed content:
- Content hash at signing — a SHA-256 hash of the document content is computed and stored with each signature. The hash covers: summary, description, status, priority, attachment metadata (filenames and sizes), and safety classification. Attachment file content is not hashed due to Forge runtime constraints.
- Content snapshot — a snapshot of the document content at signing time is stored alongside the signature. This allows auditors to see exactly what the signer saw.
- Revert on edit — when signed content changes, all signatures are automatically revoked. This prevents stale approvals and ensures the content hash always reflects the version that was actually signed.