---
id: PLAY-4
family: RT-PLAY
level: core
profiles: [runtime, editor-client]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/rt-play/play-4
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# PLAY-4 — One message row, three doors, base keys always present

*RT-PLAY (Part II) · level: core · profiles: runtime, editor-client · added in 1.0*

## The rule

> **Normative.** This is the rule.
>
> 1. The message list, the single-message read and the send acknowledgement publish the same message row.
>
> 2. Its base keys (`id`, `sessionId`, `role`, `content`, `timestamp`, `status`, `sequenceNumber`, `nodeId`, `metadata`, in that order) are always present.
>
> 3. The lineage and presentation keys `hierarchy`, `tags`, `display`, `toolArtifacts`, `parentMessageId`, `executionId`, `rootPipelineId` and `parentPipelineId` are appended only when the message carries them, and are absent otherwise rather than present and null.
>
> 4. The single-message read resolves lineage on the same terms as the list, so its row is not a lesser one.
>
> 5. `timestamp` is an ISO 8601 string.
>
> 6. The lightweight message status read is a different, four-key document (`id`, `status`, `sequenceNumber`, `timestamp`) and is not this row.

## Related rules

- Names: PLAY-3
- Referenced by: INT-22, PLAY-3

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.