Make the relationship explicit.

A record has a type, an identifier, fields, and a source reference. A relationship connects typed records through named participant roles.

Record types and fields

Use Data model → Create record type to define the fields your records can contain. The local engine supports string, number, and boolean fields, required properties, and optional enumerated values.

{
  "name": { "type": "string", "required": true },
  "status": {
    "type": "string",
    "required": true,
    "enum": ["active", "maintenance"]
  },
  "owner": { "type": "string", "required": false }
}

The metadata names id, type, and sourceId are reserved and cannot be field names. This keeps queries over record identifiers distinct from ordinary properties. Fields not present in the type definition are rejected.

Named participants

A subscription is one relationship with three roles: account, product, and plan. This preserves which plan belongs to which product subscription. Splitting it into unrelated account-to-plan and account-to-product facts can lose that association.

{
  "label": "Subscription",
  "roles": {
    "account": "Account",
    "product": "Product",
    "plan": "Plan"
  },
  "routes": [
    ["account", "product"],
    ["account", "plan"]
  ]
}

Every relationship must contain exactly the named roles in its definition. Each participant must exist and have the declared record type. The demo also supports simple two-participant relationships such as account_owner and depends_on.

The visual relationship-type builder treats the first role as the start of each forward route to the other roles. Queries may traverse those routes backwards by choosing the inverse direction.

Routes have direction

For a subscription, account → product is a forward route. Its inverse goes from the product to the account. A route does not mean every participant can reach every other participant in one hop, and it does not let a query jump between unrelated subscriptions that happen to share a plan.

Use participant filters when a condition belongs to the same relationship. For example, constrain the plan participant to Enterprise while traversing that subscription’s account-to-product route. The query reference shows the exact syntax.

Validated changes

Each accepted import or edit creates a new snapshot. Validation checks the full candidate before recording it. Invalid field values, unknown types, missing participant records, and duplicate identifiers leave the previous state unchanged.

A record with existing relationships cannot be deleted until those relationships are removed. Removing a relationship does not delete its participants. Relationship properties are JSON objects in this demo; unlike record fields, they do not have a separate typed-property schema.