Skip to main content
Version: 0.2 Draft 2

4. The PCT Lifecycle

4.1 Overview​

A PCT passes through six defined states from creation to final audit record. Each state is described below. Implementations must support all six states; they may implement additional intermediate states provided these are documented.

4.2 State 1 — Issuance​

A PCT is issued by an authorised issuer at the point a dataset is created, ingested, or enters a processing environment where PCT enforcement is active. The issuer constructs the claims object in accordance with Section 5, signs it in accordance with Section 6, and records the issuance event.

The issuer is responsible for:

  • Accurately encoding all applicable obligations as claims
  • Selecting the correct signature algorithm and key
  • Setting the issued_at and expires_at timestamps
  • Generating a globally unique pct_id

Issuer responsibility: The PCT is not a legal guarantee. It is a machine-readable attestation by the issuer that, to the best of the issuer's knowledge at the time of issuance, the claims accurately reflect the obligations attached to the data. Issuers should have governance processes in place to ensure accuracy.

4.3 State 2 — Attachment​

The issued PCT is attached to the data subject. Attachment may be implemented as:

  • A header field in an API request carrying the data
  • A sidecar metadata file travelling alongside a dataset in a pipeline
  • A field within a data envelope or wrapper
  • A reference in a data catalogue or metadata store, retrieved at verification time

Implementations must document their attachment mechanism. The attachment must be durable — the PCT must remain associated with the data throughout its journey through the system.

4.4 State 3 — Transmission​

The PCT travels with the data. Transmission may occur across network boundaries, jurisdictions, cloud environments, or AI pipeline stages. During transmission, the PCT must not be modified. Any system that modifies a PCT must re-sign it as a new issuance and record the re-issuance event, including a reference to the originating PCT by its pct_id.

4.5 State 4 — Verification​

At each enforcement point, before any action is permitted, the receiving system must verify the PCT. Verification comprises the following steps, which must be performed in order:

  1. Signature verification. Confirm that the PCT signature is valid and was produced by a trusted issuer key. If signature verification fails, the action must be blocked regardless of claim content.
  2. Expiry check. Confirm that the current timestamp is within the valid_from / expires_at window. An expired PCT must be treated as invalid.
  3. Purpose check. Confirm that the requested_purpose of the action is present in the allowed_purposes claim. If not, block.
  4. Jurisdiction check. Confirm that the action's processing_region is consistent with the jurisdiction_rules claim. If not, block.
  5. Consent check. Where the lawful_basis is consent, confirm that consent_status is true and that the consent scope covers the requested purpose. If not, block.
  6. Data category check. Confirm that any special category data indicators (data_categories) are consistent with the additional safeguards required under applicable law for the requested action. If not, block.
  7. Transfer restriction check. Where the action involves cross-border data movement, confirm that the destination is listed in permitted_destinations or that an applicable transfer mechanism is recorded. If not, block.
  8. Extension claims check. Evaluate any extension namespace claims applicable to the action context. Block if any extension claim check fails.

A single failed check is sufficient to block the action. Partial passes are not permitted.

4.6 State 5 — Decision​

Following verification, the enforcement point issues a decision: ALLOW or BLOCK. The decision, together with the specific checks that produced it, is recorded in the audit record (State 6). The decision is communicated to the requesting system via the enforcement API (see Section 7).

In addition to ALLOW and BLOCK, an enforcement point may issue a TRANSFORM decision, indicating that the action may proceed subject to a data transformation — such as redaction, pseudonymisation, or tokenisation — that brings it within the permitted claims. TRANSFORM decisions must record both the original request and the transformation applied.

4.7 State 6 — Audit​

Every verification event must produce an audit record, regardless of the decision outcome. The audit record must be generated at the time of the decision, must be tamper-evident (see Section 8), and must be retained for a period consistent with applicable regulatory requirements.

The minimum required fields of an audit record are defined in Section 8.