Modelar la Ontología

La Ontología es el modelo de datos del caso: los tipos de objeto y sus relaciones. Es lo primero que configurás. Se gestiona en /ontology (UI) o por el template + loader.

Crear un OntologyType

Un tipo tiene un id estable (es el identificador y lo referencian otros tipos), displayName, description, un icon (nombre de Lucide), una category (core / derived / use_case), y sus properties y links.

{
  "id": "Ticket",
  "displayName": "Ticket de soporte",
  "description": "Un pedido de soporte a gestionar.",
  "icon": "ticket",
  "category": "use_case",
  "properties": [ /* … */ ],
  "links": [ /* … */ ]
}

El id es inmutable tras la creación (es el doc ID y lo referencian otros tipos). Para “renombrar” se crea otro tipo y se migra. Usá identificadores tipo Ticket, OrdenDeCompra (empiezan con letra; solo letras, números o _).

Properties

Cada property declara su type, si es required, y si está indexed:

`type`	Valor	Campo extra
`string` / `number` / `boolean`	escalar	—
`date` / `datetime`	fecha ISO 8601	—
`enum`	uno de una lista	`enumValues: string[]`
`reference`	id de un objeto de otro tipo	`referenceType`

{ "name": "estado", "displayName": "Estado", "type": "enum",
  "enumValues": ["abierto", "en_progreso", "resuelto", "cerrado"],
  "required": true, "indexed": true }

⚠️

El type de una property existente es inmutable. Cambiar string → number en una property viva corrompería los objetos que ya guardaron valores. Para cambiar el tipo: borrá la property y creá una nueva con otro name. Agregar/quitar properties o editar displayName/required/indexed sí está permitido.

Links

Relaciones tipadas hacia otro tipo, con cardinalidad:

{ "name": "solicitadoPor", "displayName": "Solicitado por",
  "targetType": "Cliente", "cardinality": "one_to_one" }

one_to_one → un id.
one_to_many / many_to_many → lista de ids.
inverse opcional → el nombre del link inverso en el tipo target (consistencia bidireccional).

¿reference o link? Si una Action va a cambiar la relación (ej. reasignar un ticket), usá una property reference (las Actions modifican properties, no links). Si es una relación estructural que no muta por acciones, un link está bien.

Integridad

El backend valida la integridad referencial:

No podés crear un objeto con una reference/link a un objeto inexistente o de otro tipo.
No podés dar de baja un OntologyType referenciado por links activos de otros tipos.
Un inverse debe existir en el tipo target.

Versionado y baja

Cada tipo lleva version (optimistic locking): al editar, se valida que la versión coincida; si otro lo cambió, recibís un conflicto explícito en vez de pisar. El incremento es atómico (nunca por trigger).
La baja es soft delete (deleted: true), con restauración. Nada se borra físicamente.
Toda mutación deja un AuditEvent (domain: 'ontology') en la línea de tiempo.

Orden de creación

Si un tipo referencia a otro (property reference o link), creá primero el referenciado. En un template, ordená ontologyTypes por dependencia (ej. Cliente y Agente antes de Ticket).

Una vez modelada la Ontología, seguí con Definir Actions para darle operaciones ejecutables.

Quickstart Definir Actions