P181 — AIEP — Evidence Embargo and Timed Release Protocol

Publication Date: 2026-03-27 Status: Open Source Prior Art Disclosure Licence: Apache License 2.0 Author/Organisation: Phatfella Ltd Schema: AIEP_OS_SPEC_TEMPLATE v1.0.1 — https://aiep.dev/schemas/aiep-os-spec-template/v1.0.1

Framework Context

[0001] This disclosure operates within an Architected Instruction and Evidence Protocol (AIEP) environment as defined in United Kingdom patent application number GB2519711.2, filed 20 November 2025, the entire contents of which are incorporated herein by reference.

[0002] The present disclosure defines a protocol for managing evidence artefacts that are ingested into the AIEP corpus but held under Embargo — made available only to authorised parties — until a specified release trigger activates, at which point the artefact transitions to full corpus access according to its normal access control permissions (P166).

Field of the Disclosure

[0003] This disclosure relates to timed-release and embargo management protocols for evidence artefacts in governed artificial intelligence evidence systems.

[0004] More particularly, the disclosure concerns: an EmbargoRecord schema attached to an evidence artefact at ingestion; embargo status transitions; release trigger types; conditional release mechanisms; embargo access exceptions for authorised pre-release consumers; embargo expiry without release (automatic withdrawal); and integration with the access control protocol (P166), the archival protocol (P167), and the annotation protocol (P176).

Background

[0005] Many evidence sources carry pre-publication embargoes: scientific papers embargoed until journal publication date; regulatory documents embargoed until formal gazette publication; government statistics embargoed until official release time. An evidence corpus that ingests artefacts ahead of their public release date must manage access restrictions that are time-bounded and conditional on external trigger events.

[0006] Embargo management must be cryptographically verified and audit-logged to prevent premature release compromising the embargo agreement. The system must also handle embargo expiry — the case where an embargo period passes without the triggering release event occurring, indicating the artefact should be withdrawn rather than released.

[0007] Authorised pre-release access is also required: certain parties (e.g. fact-checkers, regulatory reviewers) may hold advance access rights to embargoed artefacts. The embargo protocol governs these exceptions without exposing embargoed content to unauthorised reasoning chains.

Summary of the Disclosure

[0008] EmbargoRecord Schema: An EmbargoRecord is attached to an evidence artefact at the time of ingestion:

• embargo_id — SHA-256 of canonical serialisation of all other fields
• subject_deid — DEID (P162) of the embargoed artefact
• embargo_status — ACTIVE, RELEASED, EXPIRED, WITHDRAWN
• release_trigger_type — one of: DATETIME (release at specified UTC datetime), EXTERNAL_EVENT (release on receipt of a signed ReleaseSignal from a designated external authority), GOVERNANCE_APPROVAL (release on approval by a designated governance node per P89), MANUAL (release only on explicit operator action)
• release_trigger_value — the specific UTC datetime, authority fingerprint, governance node ID, or null for MANUAL
• lift_window — for DATETIME triggers: a permitted early/late window in seconds (default: ±60 seconds) within which automatic lift is acceptable
• pre_release_access_tokens — list of access token identifiers (P166) that have advance READ access to the embargoed artefact
• embargo_note — free-text description of the embargo basis (not surfaced outside the embargo system)
• embargo_expires_at — optional; if the embargo is not lifted by this time, the artefact transitions to EXPIRED status and is automatically withdrawn from the corpus
• created_by — node fingerprint (P46) of the embargo-registering node
• created_at — ISO 8601 timestamp
• released_at — ISO 8601 timestamp populated when embargo_status transitions to RELEASED
• embargo_signature — cryptographic signature by the creating node

[0009] Embargo Status Transitions:

• ACTIVE → RELEASED — triggered by elapsed DATETIME, verified EXTERNAL_EVENT signal, GOVERNANCE_APPROVAL, or MANUAL operator action
• ACTIVE → EXPIRED — triggered by elapsed embargo_expires_at without a release event having occurred; the artefact is automatically moved to WITHDRAWN access status
• ACTIVE → WITHDRAWN — explicit early withdrawal by the corpus operator (e.g. embargo agreement terminated)
• All transitions are recorded to the dual-ledger (P80) and AuditLog (P171)

[0010] Release Signal Verification: For EXTERNAL_EVENT trigger type, the designated external authority submits a signed ReleaseSignal:

• signal_id — SHA-256 of canonical serialisation
• embargo_id — the embargo being lifted
• signalled_at — ISO 8601 timestamp
• signal_signature — cryptographic signature by the designated external authority The corpus system verifies signal_signature against the release_trigger_value (authority fingerprint) before executing the release transition. An invalid signal is rejected and a ReleaseSignalRejectionRecord is logged.

[0011] Embargo Access Enforcement: During ACTIVE embargo status, the access control system (P166) enforces restricted access: any access request for the embargoed artefact’s DEID is denied unless the requestor’s access token appears in pre_release_access_tokens. Denied requests are logged without surfacing the existence of the artefact (embargo-aware silence: the access denial does not reveal that an embargoed artefact exists at the requested DEID).

[0012] Annotation During Embargo: A GOVERNANCE_WARNING annotation (P176) of subtype EMBARGO_ACTIVE is attached to the artefact’s internal record during ACTIVE embargo status, visible only to governance nodes (access_level: GOVERNED_NODE). On release, the annotation transitions to EMBARGO_LIFTED type and is retained for the audit record. Pre-release access holders see a EMBARGO_ACTIVE annotation when accessing the artefact.

[0013] Batch Embargo Release: For time-coordinated releases (e.g. a statistical release of many datasets at the same UTC time), the EmbargoReleaseScheduler processes all DATETIME-triggered EmbargoRecords with a release_trigger_value within the lift_window of the current time in a single atomic batch operation, ensuring all coordinated artefacts become available simultaneously.

ASCII Architecture

Ingestion ──▶ EmbargoRecord created (ACTIVE)
              │
              ├── DATETIME trigger
              │   └── EmbargoReleaseScheduler checks periodically
              │
              ├── EXTERNAL_EVENT trigger
              │   └── ReleaseSignal received ──▶ verify signature
              │
              ├── GOVERNANCE_APPROVAL trigger
              │   └── Governance Node (P89) approves
              │
              └── MANUAL trigger
                  └── Operator action

              Embargo Status Transitions:
              ACTIVE ──▶ RELEASED (trigger fires, access opens)
              ACTIVE ──▶ EXPIRED  (embargo_expires_at passes, artefact withdrawn)
              ACTIVE ──▶ WITHDRAWN (early withdrawal)

Access Control (P166) during ACTIVE:
  pre_release_access_tokens ──▶ READ granted
  all other requestors       ──▶ denied (embargo-aware silence)

On RELEASED ──▶ normal P166 access permissions apply
              ──▶ ARTEFACT_RELEASED event ──▶ Watch (P180) subscribers
              ──▶ dual-ledger (P80) record

Operational Detail

[0014] Embargo-Aware Silence: The principle that access denial for an embargoed artefact does not reveal the existence of the artefact to unauthorised parties prevents information leakage about forthcoming releases. This applies both to direct DEID lookups (GET /evidence/{deid}) and to taxonomy-scope queries (GET /evidence?taxonomy=...) — embargoed DEIDs are excluded from query results for non-pre-release-access requestors without indicating that any results have been excluded.

[0015] Release Notification: On RELEASED transition, a ARTEFACT_RELEASED_FROM_EMBARGO event is published to the Watch Protocol (P180) for subscribers watching the affected DEID or taxonomy domain. The event does not expose the pre-release access history of the artefact.

[0016] Embargo Audit Trail: The full embargo lifecycle — creation, any access by pre-release holders, release trigger event, and release execution — is recorded to the AuditLog (P171) with a 7-year retention requirement. This supports post-publication audit of whether embargoed content was accessed by unauthorised parties prior to release.

Claims-Exclusion Notice

This specification is published as open-source prior art. No patent claims are asserted by the author in respect of the mechanisms described. Any third party seeking to patent mechanisms substantially equivalent to those described herein is placed on notice of this prior art disclosure.