Legal
Incident R13.AC — Demo data hard-purge substrate gap
Last updated May 24, 2026
This page is the incident disclosure for an internally-identified substrate gap in ShieldScore's demo-data retention discipline. It is published in the spirit of build-complete transparency. The Discovery and Containment section below preserves the 2026-05-21 snapshot of what was known at discovery time and the bridge prose published same-day to honestly disclose the gap. The Closure section is a placeholder for the substrate fill-in completion event on 2026-06-13: the T2 hard-purge cron service exits DRY_RUN observation and flips to LIVE. Customer-verifiable AuditLog evidence appears only on LIVE candidate-mutating ticks (when an organization is T2-eligible per its stored retentionUntil); if the first LIVE tick has no T2-eligible candidate, evidence publication defers to the first eligible tick or pairs with an explicit no-eligible-candidate disclosure. (The cron service itself shipped on 2026-05-24 and is currently in DRY_RUN observation — see the Status update section below for the post-ship state.)
This is not a personal-data breach under HIPAA §164.404, GDPR Art. 33, U.S. state breach-notification statutes, or SEC Item 1.05 (Form 8-K). See the Compliance posture section below for the rationale and the standards under which the substrate fill-in ETA is anchored.
Legal review pending. This incident page is in legal-review-pending status. The disclosure prose, the Compliance posture classification, and the substrate fill-in commitment dates are subject to operator-paced legal review under Static Play Compliance Governance (SPCG) counsel-of-record, bundled with the in-flight R13.AG /incidents/r13-ag legal review. Final wording and classification remain subject to operator and counsel approval. No counsel sign-off has been recorded at the date of this page's publication.
Discovery and Containment (2026-05-21)
On 2026-05-21, during codex review of merged PR #126 (the R13.AC Layer 2 backfill script + Trust Center prose triplet), we identified that ShieldScore's Data Processing Addendum and Demo Data Handling page committed to a present-tense 90-day hard-purge enforcement on ephemeral demo-organization data while the recurring substrate that would enforce that commitment — the T2 daily-sweep cron service — did not yet exist in code. The substrate gap was internally tracked (Layer 3 cron service was explicitly listed as pending in our engineering completion tracker) but the public- facing prose did not honestly disclose that gap. The codex review classified this as a build-complete-doctrine outcome-4 (claim/substrate mismatch) active in production.
Today (2026-05-21), we are shipping bridge prose to the DPA and Demo Data Handling page that honestly discloses the current substrate state: demo organizations that have reached the T1 boundary remain soft-tombstoned with cryptographically-signed deletion receipts (RS256 via AWS KMS, verifiable against our published JWKS at /.well-known/jwks.json); the T2 hard-purge automation is in build, with a committed deployment date of 2026-06-13. Customer-trust posture: zero ShieldScore customer contracts cite this DPA at the time of this disclosure (pre-revenue).
The substrate fill-in was originally sequenced on 2026-05-21 as a four-PR plan (the text below is the 2026-05-21 plan; it has been partially superseded by the actual shipped substrate — see the Status update section below for the current arc state):
- PR-α (this PR) — Honest bridge prose published to the DPA, Demo Data Handling page, and this incident page. Engineering hands-off on prose wording after the operator-paced legal review converges (bundled with the in-flight R13.AG legal review under SPCG counsel-of-record).
- PR-β (next, after PR-α merge) — Substrate fixes to the R13.AC Layer 2 backfill script for three codex findings (receipt- signing atomic boundary; halt-state audit-log emission; predicate-gating correctness post-Layer 1 writer-side activation). All three fixes ship with structural-contract tests per the enforcement-substrate methodology.
- PR-γ (after PR-β merge) — R13.AC Layer 3 T2 cron service ships in DRY_RUN mode. Daily sweep query
WHERE orgType='DEMO' AND tombstonedAt + INTERVALwith per-organization Serializable transaction, FK-rewrite to per-org system sentinel actor, PII purge of cascade child rows, and audit-log emission. DRY_RUN observation runs through the confirmed 2026-06-13 LIVE flip target.retention_daysdays < NOW() - PR-δ (lockstep with PR-γ LIVE flip on 2026-06-13) — Final prose republication: DPA and Demo Data Handling page return to present-tense honest claims; this incident page is closed with resolution citation and AuditLog Merkle-witness evidence of the first cron tick. SPCG counsel-of-record sign-off in the page footer.
Arc state as of 2026-05-24 (supersedes the 2026-05-21 plan above where they differ):
- PR-α SHIPPED as PR #150 + metadata follow-up PR #151 on 2026-05-21.
- PR-β SHIPPED as PR #152 on 2026-05-22 (squash commit
3915e2c). - PR #125 follow-up (writer-side
orgTypeclassification — added to the arc after the 2026-05-21 plan was written) SHIPPED as PR #153 on 2026-05-23 (squash commit4de180a). - PR-γ SHIPPED as PR #154 on 2026-05-24 (squash commit
1af812c). Currently in DRY_RUN observation through the 2026-06-13 LIVE flip target. The shipped T2 predicate uses storedretentionUntil <= NOW()(the value computed and stored on each Organization row at tombstone time), NOT thetombstonedAt + INTERVAL retention_daysquery in the 2026-05-21 plan above — the stored-value approach prevents drift ifTRUST_CENTER_DEMO_RETENTION_DAYSis reconfigured for future orgs after old orgs have already been tombstoned. - PR-δ-pre (this PR — added to the arc to honor the lockstep promise above) is the state-refresh prose disclosure: it republishes
/dpa,/demo-data-handling, and this incident page to reflect the post-PR-γ-ship substrate state without claiming closure. - PR-δ-final remains scheduled in lockstep with the 2026-06-13 LIVE flip per the Closure section below; the closure evidence requirement is qualified there (LIVE candidate-mutating tick OR explicit no-eligible-candidate disclosure).
Status update — 2026-05-24 (PR-γ shipped)
The R13.AC Layer 3 cron service (PR-γ in the 4-PR remediation arc above) shipped to production on 2026-05-24 as PR #154 (squash commit 1af812c) after a 3-amendment codex-review trail. The accompanying schema migration 20260523_r13_ac_sweep_lease applied cleanly during the Railway release phase, and Railway deploy 2ba19a2c reached SUCCESS the same day. The Tombstone Two-Timer is now the seventh registered scheduler in the API container (13-minute boot stagger, 1-day fire interval) and is in DEMO_ORG_SWEEP_DRY_RUN=true mode.
What that means today: the T2 hard-purge substrate is live in code and the daily sweep runs on schedule, but in DRY_RUN it performs no database writes — no candidate organization is mutated, and no AuditLog rows are produced. The service emits AuditLog EPHEMERAL_DEMO_TOMBSTONED and ORG_HARD_PURGED rows only on LIVE candidate-mutating paths; DRY_RUN ticks return summary objects with auditLogEmitted: false and produce only operator-visible scheduler/log/result evidence. This is the planned ~21-day DRY_RUN observation window through the 2026-06-13 LIVE flip target.
Lockstep promise preserved: PR-δ in the 4-PR arc above commits to final prose republication and incident closure in lockstep with the LIVE flip on 2026-06-13. This Status update is a state-refresh disclosure (PR-δ-pre); it reports the ship event without claiming closure. The Closure section below remains a placeholder until the LIVE flip happens AND a LIVE candidate-mutating cron tick either (a) writes an EPHEMERAL_DEMO_TOMBSTONED or ORG_HARD_PURGED AuditLog row that can be cited as the closure Merkle-witness, or (b) reports explicitly that no candidate was eligible at that tick (in which case closure is either deferred to the first eligible tick, or published with an explicit “no eligible candidate yet” disclosure).
DPA and Demo Data Handling page updates: the bridge prose on /dpa and /demo-data-handling has been refreshed in the same PR to reflect “T2 hard-purge automation shipped 2026-05-24, currently in DRY_RUN observation through the 2026-06-13 LIVE flip” rather than the prior “in build for 2026-06-13” framing. The honest-disclosure posture is unchanged: bridge state remains in force until the LIVE flip; full present-tense claims will return on PR-δ-final at LIVE flip.
No new customer-impacting state change: no demo organization has been hard-purged. The 14 EPHEMERAL_DEMO_STALE rows that predated PR-γ were live-tombstoned on 2026-05-17 (via the L2 backfill --execute run; audit artifact at docs/operational/audits/r13-ac-backfill-2026-05-17T00-29-36-718Z.json) and carry a stored retentionUntil of 2026-08-15T00:29:15.869Z. They are not eligible for T2 hard-purge at the 2026-06-13 LIVE flip — they survive the flip in their T1 (soft-tombstoned, access-blocked, signed-receipt) state and become eligible for the first T2 cron tick whose run time is at or after their retentionUntil (approximately 2026-08-15).
Closure — pending (target 2026-06-13)
This section is reserved for the substrate fill-in closure disclosure to be published at PR-δ-final, in lockstep with the 2026-06-13 LIVE flip and the first eligible LIVE T2 tick. The closure will contain either (a) the AuditLog Merkle-witness row identifier for a LIVE candidate-mutating tick that wrote an EPHEMERAL_DEMO_TOMBSTONED or ORG_HARD_PURGED row, or (b) an explicit no-eligible-candidate disclosure if no organization has reached its stored retentionUntil during the closure window (with closure either deferred to the first eligible tick or published with that explicit disclosure). The closure will also include an independent self-test mirroring the verification pattern from Incident R13.AG's closure section, and the SPCG counsel-of-record ruling that closes this incident.
Compliance posture
This incident is not a breach-notification event under HIPAA §164.404, GDPR Art. 33, U.S. state breach-notification statutes, or SEC Item 1.05 (Form 8-K) per the Static Play Compliance Governance (SCG) ruling dated 2026-05-21 (no unauthorized acquisition, access, use, or disclosure of personal data; claim/ substrate mismatch on a customer-facing temporal commitment, not a data-protection failure). The substrate fill-in ETA is a buyer- trust calibration anchored in SOC 2 CC2.3 (communication of information to external parties), AICPA SSAE 21 §AT-C 105.A29 (matters affecting subject- matter evaluation), and NIST CSF 2.0 RC.CO-04 (recovery activities and progress communicated to stakeholders). Auditor disclosure under our existing SOC 2 Type II audit relationship will reflect this incident in the next management- response section per TSC CC7.1 (detection of events and anomalies) and CC9.2 (vendor and business- partner risk management).
The institutional pattern identified by this incident — that customer-facing prose with present-tense or forward-binding temporal language must ship with or strictly before the enforcement substrate that honors it — has been added to ShieldScore's build-complete doctrine extension (P-15) under SPCG governance.
Questions or verification requests
For verification questions, substrate-state-at-a-specific-date requests, or correspondence under our existing customer-trust agreements, contact privacy@shieldscore.ai. The canonical decision record and remediation evidence are maintained in our public source repository under docs/operational/sessions/ and the incident-specific audit artifacts will be linked from this page at PR-δ closure.