Everything is JSON-LD

Closure’s paradigm is simple:

If it is part of the product, it is a typed object on the product graph — not a special case in application code.

We represent those objects as JSON-LD (JSON for Linked Data): plain JSON with @id, @type / schemaRef, and data fields the runtime understands. Wondering why a graph at all — and why not YAML, SQL, or Mongo? Why a Product Graph? answers that head-on.

Why this matters

Traditional stacks split the product across:

• a CMS or React tree for UI
• a BPM / workflow engine for process
• a vector DB + prompts for AI
• an iPaaS for integrations

Closure collapses that into one graph. Your IDE and the Platform APIs mutate the same objects humans edit in the console. Deploy is promotion of graph state — not a separate build artifact for “the app.”

Anatomy of a DataObject

Two fundamentals — everything else is a projection of these:

{
  "@context": "https://closureapps.com/schema/context.jsonld",
  "@id": "urn:uuid:7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "schemaRef": "schema:experience",
  "name": "CRM Lite",
  "orgId": "org_acme",
  "state": "active",
  "data": {
    "slug": "crm-lite",
    "homePath": "/",
    "nav": [
      { "label": "Contacts", "href": "/" },
      { "label": "Add", "href": "/new" }
    ]
  }
}

A page is another DataObject. A component is another. A workflow graph is another. A skill (short playbook for AI agents) is another. Same store. Same APIs — query via GraphQL, execute process via Workflows API.

Workflow as data (sketch)

{
  "@id": "urn:uuid:…",
  "schemaRef": "schema:workflow",
  "name": "Lead capture",
  "data": {
    "workflowId": "wf-lead-capture",
    "nodes": [
      { "id": "collect", "kind": "collect", "form": { "fields": ["email", "name"] } },
      { "id": "notify", "kind": "tool", "tool": "email.notify" }
    ],
    "edges": [{ "from": "collect", "to": "notify" }]
  }
}

Forms, chat turns, and agent steps are projections of this graph — not three products.

What the runtime does

1. Store & query the graph (GraphQL / APIs)
2. Authorize by org + policy
3. Run workflows under governance (HITL, audit → Events)
4. Render Experiences from page/component objects
5. Seal structured results into systems of record via Integrations

Code around the graph is the kernel. The product you ship is the graph.

Next

• Pillars — Experiences · Workflows · Knowledge · Integrations
• The Product Graph — longer essay
• Quickstart — install into your IDE and inspect objects on the graph