Reference
Data endpoints
Every field on a data endpoint, with tables and examples.
Data endpoints are the named read and write points workflows use. A source node reads from one; a destination node writes to one; the ontology store is one. Integrations own the connection — endpoints name the usable doors. Connection side in Data and integrations.
Identity fields
| Field | Meaning | Rules |
|---|---|---|
| Name | Human reference workflows point at | Stable — renaming breaks every node naming it |
| Namespace | Grouping, usually the system or domain | Keeps crm.orders distinct from warehouse.orders |
| Description | What the door is for, who uses it | Write for the next operator |
{
"name": "crm.orders",
"namespace": "crm",
"description": "Order stream for renewal analytics. Owner: revenue ops."
}Image: endpoint list showing name, namespace, role, and health.
Role and contract
| Field | Values | Meaning |
|---|---|---|
| Role | source, destination, ontology store, event source/sink, API, file store, search index, graph store, other | Which node kinds may use it |
| Contract kind | stream read, query read, plain read, write, API call, event subscribe/publish, ontology fact store, transactional table | The access pattern — match need to kind |
| Target | At least one selector field | The concrete table, path, stream, or object |
| Accepts / emits | Data formats in and out | Emits default analytics columnar; change only when consumers demand |
{
"name": "warehouse.forecast_output",
"namespace": "warehouse",
"role": "destination",
"contractKind": "write",
"target": { "schema": "analytics", "table": "forecast_scores" },
"emits": "parquet"
}Schema hints
| Field | Meaning | Example |
|---|---|---|
| Columns | Expected fields — documentation for mappers, not enforcement | ["order_id", "total", "placed_at"] |
| Primary key | Row identifiers feeding downstream identity | ["order_id"], or ["account_id", "snapshot_date"] |
Trust and ownership
| Field | Values | Meaning |
|---|---|---|
| Trust rank | Low / medium / high | How much downstream work should lean on it; review on schedule |
| Owner team | Team name | Who fixes the door when it breaks |
| Freshness | Expected currency | The promise staleness is judged against, e.g. "hourly" |
Forecasts built on low-trust doors deserve extra skepticism at dry-run.
Write governance
| Field | Meaning |
|---|---|
| Write policy | Rules on mutations, identity, duplicates, conflicts, retention |
Full catalog in Write policies. A destination without one is a door without rules — do not commit it.
Choosing well
- One endpoint per real door — share endpoints, version workflows.
- Namespaces mirror systems, not teams: systems outlive reorgs.
- Trust ranks get reviewed on a schedule, or every door quietly becomes medium and the rank means nothing.