Mission entity schemas use id as the canonical identity field, with entity id values owned by the daemon in table:uniqueId form. Relationship fields use explicit domain names such as missionId, repositoryId, stageId, or taskId, but an Entity’s own identity is always id so JSON-backed storage and future database-backed storage share the same identity model. Entity schemas must not duplicate their own identity under entity-specific names such as artifactId, stageId, or taskId; those names are valid only when they reference another Entity or a non-Entity domain concept owned by a different schema.

Every canonical Entity storage record also carries the base Entity timestamps createdAt and updatedAt, validated by the shared DateTimeSchema. These fields belong to EntityStorageSchema and therefore flow into EntitySchema; concrete Entity storage schemas must not re-declare duplicate timestamp fields unless a separately named domain timestamp is needed for a different concept. createdAt records Entity storage creation time, while updatedAt records the last Entity storage update time.

Filesystem paths are never canonical Entity identity. A path may describe a checked-out Repository location, Mission worktree location, Artifact file root, execution working directory, or daemon-local filesystem target, but it must not be the primary key, owner id, remote invocation target, or durable relationship identity for Repository, Mission, Task, AgentExecution, or any other first-class Entity once that Entity exists. Repository-owned behavior is addressed by repositoryId; Mission-owned behavior is addressed by missionId; path fields remain operational location data only.

Names must describe the shape or behavior they own without relying on hidden context. Opaque generic names, misleading contextual names, and ambiguous container words are forbidden. A schema name must describe the data it validates; a property name must describe the value it carries; a method name must describe the behavior it exposes. Context words such as event, subject, reference, address, document, snapshot, content, or compatibility-era domain names may be used only when that concept is actually present in the shape and is part of the current Mission vocabulary. If two names can plausibly describe the same value, the code must converge on the canonical domain name rather than keeping both.

snapshot is valid only for a point-in-time read model that is not the same schema-backed concept as the underlying Entity. System snapshots, terminal snapshots, worktree snapshots, state store snapshots, and aggregate Mission snapshots may use the term when they compose, freeze, or observe multiple underlying records or runtime state. snapshot must not be used as an alias for an Entity’s <Entity>Schema. Entity change events that carry transitional child Entity data use data and data.changed; Entity change events that carry a complete hydrated Entity use the canonical Entity field name, such as mission, validated by <Entity>Schema.

Entity schema modules are not behavior owners. They preserve separate input, storage, and hydrated Entity schema roles, and keep field and relationship metadata close to validation so persistence, indexing, event publication, and future database mapping can share one source of truth. Entity contracts bind those schemas to an Entity class’s remote methods and presentation metadata, but the Entity class owns the behavior and invariants.

These schema roles also define the future replication contract. <Entity>InputSchema describes the daemon-validated input required to create or register an Entity. Method-specific input schemas describe daemon-validated mutation intent for existing Entities and any future surface-local command outbox payloads. <Entity>StorageSchema describes canonical persisted Entity records and is the only Entity record shape eligible for daemon-to-surface replication as source of truth. <Entity>Schema describes the fully hydrated Entity instance exposed by the Entity boundary, including computed fields, linked Entity data, workflow read material, and commands; it must not be treated as replicated source of truth.