AI Ingestion
Status Update Payloads
The Parallel Ledger uses a fixed-slot schema to store varied data types. Rather than defining a custom table for every business use case, you map your data into the four primitive "status" fields provided by the protocol.
The Data Slots
Each Status Update can utilize any combination of the following four fields. If a property requires multiple types (e.g., a label and a numeric value), they can be sent within the same update.
status_dt
Unix Microseconds
Used for secondary timestamps or historical markers (e.g., an ETA or effective_date). The Ledger does not perform timezone conversion; all values are treated as raw UTC microseconds.
status_int
Unsigned BigInt
64-bit integer storage. Ideal for counters, financial amounts in minor units (cents), or boolean states (0 or 1).
status_slug
String (255)
A short-string reference often used to associate the current entity with another entity (e.g., mapping a sub_contract slug to a parent_contract slug).
status_text_value
String (2600)
Unstructured string data for notes, descriptions, or external references.
Capacity Note: This field is capped at 2,600 characters to ensure sub-millisecond indexing and cryptographic hashing performance. If you exceed this limit, the system will reject the update.
Don't use this field for JSON blobs; instead, decompose complex objects into separate property codes.
Permanent vs. Redactable Data
It is critical to distinguish between Status Slugs (system-level labels) and Status Text Values (raw data) when designing your schema.
:status_slug (Permanent)
Slugs are treated as architectural constants. Because they are presumed to be reused system values (e.g., STATUS_ACTIVE), they are never removed from the system dictionary during Tombstoning.
USER_PHONE_555_0199. It cannot be scrubbed.
:status_text_value (Redactable)
Text values are treated as transient payloads. These are the primary targets for redaction. When a record is Tombstoned, these values are wiped and purged from the string dictionary.
Authority & Attribution
Beyond the data slots, every update must identify the initiating authority to complete the audit trail.
executed_by_slug
This field identifies the specific actor—whether a human user ID, a service bot, or an automated system—that asserted this value as fact. This slug is permanent and provides the "who" in the Who/What/When audit triad.
Status Update Payloads
The Parallel Ledger uses a fixed-slot schema to store varied data types. Rather than defining a custom table for every business use case, you map your data into the four primitive "status" fields provided by the protocol.
The Data Slots
Each Status Update can utilize any combination of the following four fields. If a property requires multiple types (e.g., a label and a numeric value), they can be sent within the same update.
status_dt
Unix Microseconds
Used for secondary timestamps or historical markers (e.g., an ETA or effective_date). The Ledger does not perform timezone conversion; all values are treated as raw UTC microseconds.
status_int
Unsigned BigInt
64-bit integer storage. Ideal for counters, financial amounts in minor units (cents), or boolean states (0 or 1).
status_slug
String (255)
A short-string reference often used to associate the current entity with another entity (e.g., mapping a sub_contract slug to a parent_contract slug).
status_text_value
String (2600)
Unstructured string data for notes, descriptions, or external references.
Capacity Note: This field is capped at 2,600 characters to ensure sub-millisecond indexing and cryptographic hashing performance. If you exceed this limit, the system will reject the update.
Don't use this field for JSON blobs; instead, decompose complex objects into separate property codes.
Permanent vs. Redactable Data
It is critical to distinguish between Status Slugs (system-level labels) and Status Text Values (raw data) when designing your schema.
:status_slug (Permanent)
Slugs are treated as architectural constants. Because they are presumed to be reused system values (e.g., STATUS_ACTIVE), they are never removed from the system dictionary during Tombstoning.
USER_PHONE_555_0199. It cannot be scrubbed.
:status_text_value (Redactable)
Text values are treated as transient payloads. These are the primary targets for redaction. When a record is Tombstoned, these values are wiped and purged from the string dictionary.
Authority & Attribution
Beyond the data slots, every update must identify the initiating authority to complete the audit trail.
executed_by_slug
This field identifies the specific actor—whether a human user ID, a service bot, or an automated system—that asserted this value as fact. This slug is permanent and provides the "who" in the Who/What/When audit triad.