Build a data model with AI

Don't want to draw it by hand? Let Claude, ChatGPT or Gemini sketch a starter model from a plain description of your business — then import it here and push it into OWOX Data Marts in one click.

Then paste them into Claude, ChatGPT or Gemini.

How it works

Copy the instructions
Use the button above — it copies a short brief that teaches the AI our format.
Paste into Claude, ChatGPT or Gemini and describe your data
Tell it about your business and the tables you have ("we're an e‑commerce shop with customers, orders and products…"). It replies with a ready‑to‑import model.
Import it here, then Push to OWOX
Open Import on the canvas, paste what the AI gave you, check the graph looks right, and click Push to OWOX to create the draft Data Marts.

Prefer to start from something ready‑made? You don't need AI at all — open Templates on the canvas and roll out a model for your industry, or just draw one yourself.

Want the exact format the assistant follows? It's spelled out in full below — and also lives, copy‑ready, at /okf-format.md.

Instructions for an AI agent (Claude, Codex, Gemini, …) to generate a data model in OKF that imports cleanly into OWOX Model Canvas and pushes to OWOX Data Marts in one click.

Goal. Produce one or more Markdown documents in the format below. The user pastes or uploads them into Import OKF on the canvas, reviews the rendered graph, then clicks Push to OWOX to create draft Data Marts and joinable relationships.

1. What is OKF

Open Knowledge Format (OKF) represents metadata as a folder of Markdown files with YAML frontmatter. Reference: GoogleCloudPlatform/knowledge-catalog (the okf/ spec) and OWOX's own bundles at github.com/OWOX/models. This canvas reads and writes that bundle format: one document per Data Mart, a ## Overview block, a # Schema table, and a ## Joins section. Export OKF on the canvas produces exactly this format, so anything you generate here round-trips.

2. Two ways to provide a model

Both use the same per-document format (section 3) and differ only in packaging:

A — Single file / paste. Put every document in one .md (or paste them), each preceded by a marker comment  that separates the docs:
```

---
...frontmatter...
---
# Customers
...


---
...frontmatter...
---
# Orders
...
```
The  markers are this canvas's convention for packing several documents into one file.
B — ZIP bundle. A folder with an index.md plus one <slug>.md per Data Mart, zipped. This is exactly what Export OKF downloads and matches the OWOX/models layout. The user uploads the single .zip in Import OKF and the whole model loads at once — no need to upload files one by one.

Pick whichever fits your workflow; the canvas imports both.

3. Anatomy of a Data Mart document

---
type: "OWOX Data Mart"
title: "Orders"
description: "One row per order"
tags: ["owox", "sql"]          # 2nd tag = input source (lowercased), used as a fallback
---

# Orders

One row per order, used for revenue and retention.

## Overview

- **ID:** `—`                  # leave as — ; filled after Push to OWOX
- **Status:** DRAFT
- **Definition type:** SQL      # SQL | CONNECTOR | VIEW | TABLE — sets the input source
- **Storage:** —               # leave as — ; the canvas applies the selected storage

# Schema

| Column | Type | Description |
|--------|------|-------------|
| `id` | STRING | PK. Unique order identifier |
| `customer_id` | STRING | FK to [Customers](./customers.md) |
| `order_date` | DATE | |
| `total` | FLOAT | Order total, gross |

## Definition

```sql
SELECT id, customer_id, order_date, total FROM `project.dataset.orders`
```

## Joins

- [Customers](./customers.md) — `customer_id = id`

Frontmatter fields

type — always "OWOX Data Mart".
title — human title (shown on the node). The relationship id is the title's slug — lowercase, spaces → hyphens (e.g. Order Items → order-items.md) — so keep titles distinct.
description — one-line summary (optional).
tags — ["owox", "<input source lowercased>"], e.g. ["owox","view"].

4. Output schema (fields)

List the mart's columns in a # Schema table with three columns:

Column — field name in backticks (required).
Type — one of the allowed types below (required).
Description — a short note (optional). Two markers live here:
- Primary key — start the Description with PK. (e.g. PK. Unique id).
- Foreign key — write FK to [Target Title](./target-slug.md).

Allowed types (cross-storage canonical set — do not use others like DATETIME):

STRINGINTEGERFLOATNUMERICBOOLEANDATETIMETIMESTAMPBYTESGEOGRAPHYVARIANT

5. Definition (optional)

Optionally include a ## Definition fenced code block. Its meaning depends on the Definition type in Overview:

SQL — a SQL query (use a ```sql fence), e.g. SELECT … FROM `project.dataset.table`.
TABLE — a fully-qualified table name, e.g. project.dataset.table.
VIEW — a fully-qualified view name, e.g. project.dataset.view (a reference, not a SQL query).
CONNECTOR — omit; configured in OWOX after creation.

6. Relationships (Joins)

Declare joinable relationships in a ## Joins section on the source mart. Each line links to the target document and states the join condition:

## Joins

- [Customers](./customers.md) — `customer_id = id`
- [Products](./products.md) — `product_id = id`

Format: - [Target Title](./target-slug.md) — `leftField = rightField`. Multiple keys: comma-separate the backticked pairs.
The filename slug is the target title lowercased with spaces → hyphens (e.g. Order Items → order-items.md).
Join fields should exist in both marts' # Schema. It also helps to mark the source field with FK to [Target](./target-slug.md) in its Description.
Bidirectional relationship: add a matching Joins line in both documents (with the key sides swapped). The canvas renders it as a double-headed arrow.
Cardinality (optional): append a classic ER cardinality after the keys — - [Target](./target-slug.md) — `leftField = rightField` [1:N]. Allowed: 1:1, 1:N, N:1, N:N, oriented source → target. It is for modeling/visualization only (shown as a pill on the canvas); it is ignored by OWOX (its SQL aggregates) and does not affect Push.

7. Complete minimal example

<!-- shop/customers.md -->
---
type: "OWOX Data Mart"
title: "Customers"
tags: ["owox", "view"]
---
# Customers

## Overview
- **Definition type:** VIEW

# Schema
| Column | Type | Description |
|--------|------|-------------|
| `id` | STRING | PK. Unique customer id |
| `email` | STRING | Primary contact email |

<!-- shop/orders.md -->
---
type: "OWOX Data Mart"
title: "Orders"
tags: ["owox", "view"]
---
# Orders

## Overview
- **Definition type:** VIEW

# Schema
| Column | Type | Description |
|--------|------|-------------|
| `id` | STRING | PK. Unique order id |
| `customer_id` | STRING | FK to [Customers](./customers.md) |

## Joins
- [Customers](./customers.md) — `customer_id = id`

8. Workflow

Generate the documents above for the user's domain — as a single file with  markers, or as a ZIP bundle.
User opens Import OKF, pastes the text / uploads the .md / uploads the .zip, clicks Import.
The canvas renders nodes + relationships; the user reviews and tweaks.
User picks a Storage and clicks Push to OWOX → draft Data Marts, output schemas and joinable relationships are created in the OWOX project.
Optional: Export OKF downloads the model as a .zip bundle in this same format; re-importing that .zip restores the model.

Rules of thumb. Keep titles distinct (the slug wires relationships). Use only the allowed schema types. Mark one PK. per mart and reference real fields in joins. Leave ID/Storage as — — the canvas fills them.