Apex Intelligence Empire

Balaclava, Victoria Australia kawaljeet.singh3008@gmail.com https://apex-infrastructure.com

PSI-06 specifies an inception-lock protocol that cryptographically anchors a raw human-originated data signal (keystroke, biometric, survey response, application screen capture, trip acceptance timestamp) to a signing key at the point of capture. The protocol prevents tampering with source data between capture and submission, enabling verifiable proof of what a user was shown and when they saw it. Receipts are protected by a hybrid dual-signature scheme combining Ed25519 (classical) and ML-DSA-65 (post-quantum), making the evidence chain resistant to both classical and quantum adversaries. This is critical for accountability proceedings involving algorithmic platforms, where the information displayed to the user may differ from the information recorded by the platform.

Human-originated data is the most vulnerable point in any integrity chain. When a platform displays a time estimate of "55 min, $25" without qualifying language such as "estimated", the user's experience of that moment diverges from the platform's later recorded data. PSI-06 defines an inception-lock that signs the signal at the point of capture, before any processing or storage, enabling the user to prove what they saw and when. This has direct application to algorithmic accountability proceedings. In the case of gig-economy dispatch platforms, workers accept task offers based on displayed time and earnings estimates. The platform's recorded data may differ from what was displayed. The inception-lock protocol closes this evidentiary gap with a receipt that the platform cannot alter.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The capture device MUST:

1. Canonicalise the raw signal with RFC 8785 (JCS).
2. Sign the canonicalised signal with an Ed25519 key provisioned in hardware or in a trusted execution environment.
3. Sign the same canonicalised signal with an ML-DSA-65 post-quantum key, forming a hybrid dual signature.
4. Emit an inception-lock receipt before returning control to the capturing application.

The receipt MUST include:

• signal_digest: SHA-256 of the canonicalised signal.
• device_id: hardware-bound public key fingerprint.
• captured_at: RFC 3339 timestamp with microsecond precision.
• application_id: identifier of the capturing application.
• display_hash: SHA-256 of the screen content at capture time.
• signature_classical: Ed25519 signature over all preceding fields.
• signature_pq: ML-DSA-65 signature over all preceding fields.

", "device_id": "", "captured_at": "", "application_id": "", "display_hash": "", "signature_classical":"", "signature_pq": "" } ]]>

A verifier MUST recompute the SHA-256 digest over the canonicalised signal and validate BOTH signatures. A receipt failing either signature check MUST be treated as unsealed and MUST NOT be admitted into an integrity chain. Implementations MAY additionally anchor the receipt digest in a public PSI-04 ledger to obtain an independent third-party timestamp.

When a gig-economy worker accepts a task offer, the application displays time and earnings figures. The inception-lock captures:

• The displayed time estimate (e.g., "55 min").
• The displayed earnings estimate (e.g., "$25").
• The absence of qualifying language (e.g., "estimated", "approximately").
• The exact timestamp of acceptance.

This creates a cryptographically verifiable record of what the worker was shown at the moment of decision. The platform's internal records of what was displayed can be compared against the inception-locked evidence; discrepancies become provable in formal proceedings. Because the receipt carries a hybrid dual signature, the evidence chain remains valid across the post-quantum transition horizon of such proceedings.

The inception key MUST reside in hardware-backed secure storage (TPM 2.0, Secure Enclave, or equivalent). Software-only keys are acceptable for evidentiary purposes but MUST be disclosed to the trier of fact. The hybrid scheme protects against harvest-now, decrypt-later adversaries: the ML-DSA-65 signature remains valid even if Ed25519 is later broken by cryptographically relevant quantum computers. The protocol does not prevent the platform from altering its internal records. It creates an independent chain of evidence that the platform cannot alter.

The inception-lock receipt contains no personally identifying information beyond the device identifier. Implementations SHOULD support pseudonymous device identifiers that cannot be linked to a natural person without additional information held solely by the user.

This document has no IANA actions.

References NIST Apex Intelligence Empire