binder-modeling

Binder Data Modeling

Schema is stored as data — types and fields are config entities that evolve through transactions.

Core Concepts

• Field — first-class schema element (name, data type, constraints). Shared across types (RDF-style)
• Type — organizes entities and applies field constraints. Any entity can have any field
• Transaction — atomic changes to multiple entities. Schema changes use binder tx import

Namespaces

• Record — user data. References use UIDs
• Config — schema (Fields, Types, Attributes). References use immutable keys
• Transaction — append-only audit log

Defining Fields

Fields exist independently of types. Define in a transaction YAML and import with binder tx import:

- author: system
  configs:
    - key: priority
      type: Field
      name: Priority
      dataType: option
      options: [low, medium, high]
      default: medium

    - key: assignee
      type: Field
      name: Assignee
      dataType: relation
      range: [User]

Defining Types

Types compose fields with optional per-type constraints:

- author: system
  configs:
    - key: Task
      type: Type
      name: Task
      fields:
        - title: { required: true }
        - status: { default: active, only: [draft, active, complete] }
        - priority
        - parent: { only: [Task] }
        - children: { only: [Task] }

Constraints: required, default, only: [...], exclude: [...].

Relations

Use inverseOf for bidirectional sync. See references/relations.md for patterns and storage details.

1:M — allowMultiple side declares inverseOf, single-value side stores data:

    - key: parent
      type: Field
      dataType: relation
    - key: children
      type: Field
      dataType: relation
      allowMultiple: true
      inverseOf: parent

M:M — both sides allowMultiple, both store data:

    - key: relatesTo
      type: Field
      dataType: relation
      allowMultiple: true
      inverseOf: relatesTo