Skip to content
AtomPRD

Domain (2)

entity — ent_

Section titled “entity — ent_”

A domain concept — a noun in your project (Habit, User, Order, Invoice, …).

{
  "id": "ent_habit_h7h8",
  "kind": "entity",
  "name": "Habit"
}

Fields are NOT nested. Each field is its own field atom referenced by entityId. This means:

  • A field rename is a single atom edit, not a nested object splice.
  • Fields have stable IDs and can be cross-referenced by criterion.behavior.before_after.state_diff paths.
  • The cloud authoring UI can list / search across fields globally without walking entity sub-trees.

field — fld_

Section titled “field — fld_”

A column on an entity.

{
  "id": "fld_habit_name_q4q4",
  "kind": "field",
  "name": "name",
  "entityId": "ent_habit_h7h8",
  "dataType": "string",
  "required": true
}

dataType is one of string / number / boolean / date / datetime / enum / reference / json.

For enum, the cloud editor surfaces an options[] field. For reference, a referencesEntity field pointing to another entity ID.

Wiring

Section titled “Wiring”

A typical entity layout:

ent_habit_h7h8 (entity)
├── parent_of → fld_habit_id_q4q4
├── parent_of → fld_habit_name_q5q5
└── parent_of → fld_habit_frequency_q6q6

The cloud sets field.entityId = ent_habit_<hash> automatically when you add a field under an entity. Hand-authored manifests must set both the entityId field and the parent_of edge.

Pattern C inference uses entity + field

Section titled “Pattern C inference uses entity + field”

When a ui_view has viewType=list and a rendered_by edge to an entity, Pattern C reads the entity’s field children and templates a list screen with one row per record:

List view template
├── heading: "<entity.name>"
├── list:
│   source: state.<entitySlot>
│   itemTemplate:
│     - text: { $ref: "item.<field1>" }
│     - text: { $ref: "item.<field2>" }

Same idea for viewType=form (one input per field) and viewType=detail (one row per field).

See also

Section titled “See also”