docs: rewrite press releases + add alpha notice to README

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: shagility-notabot

README.md

@@ -4,6 +4,11 @@ Define data contracts for your data assets — the agreement between the team th
 
 An [AgileDataGuides](https://agiledataguides.com/agiledata-templates/) Pattern Template app.
 
+## ALPHA VERSION
+
+This is the initial stubs version of the app, publishing it so I can collaborate with a few people on what the Data Contract app should actually look and behave like.
+
+
 ## What It Does
 
 A Data Contract is an explicit, machine-readable agreement covering everything a consumer needs to depend on a dataset:

app/README.md

@@ -4,6 +4,11 @@ Define data contracts for your data assets — the agreement between the team th
 
 An [AgileDataGuides](https://agiledataguides.com/agiledata-templates/) Pattern Template app.
 
+## ALPHA VERSION
+
+This is the initial stubs version of the app, publishing it so I can collaborate with a few people on what the Data Contract app should actually look and behave like.
+
+
 ## What It Does
 
 A Data Contract is an explicit, machine-readable agreement covering everything a consumer needs to depend on a dataset:

data/stripe-customers-contract.json

@@ -24,7 +24,7 @@
     "master-data"
   ],
   "changeDetection": [
-    "Change Data Capture (Database Logs)"
+    "Change Data Capture (Other)"
   ],
   "retentionPeriod": [
     "7 years"

press-releases/001-initial-data-contract-app.md

@@ -0,0 +1,41 @@
+# Data Contract App Now Available
+
+**9 April 2026**
+
+AgileDataGuides today released the Data Contract, a free, open-source app that helps data teams capture the agreement between the team that produces a dataset and the teams that consume it. The contract covers schema, quality expectations, freshness commitments, ownership, and the business glossary terms that anchor the dataset in the team's domain language.
+
+## The Problem
+
+Most "data contract" conversations end up as a slide deck, a Confluence page, or an Excel sheet that nobody reads after the first sprint. The producer team promises a schema and a refresh cadence, the consumer team builds against it, and six months later the producer changes a column type without telling anyone. There's no single living artefact that names what the producer commits to, what the consumer depends on, and how to tell when the contract has been broken.
+
+## The Solution
+
+The Data Contract app gives every dataset a single canvas that captures everything a consumer needs to depend on it:
+
+- **Data Asset** — the dataset the contract governs
+- **Schema / Columns** — every column with type, nullability, and classification
+- **Quality Rules** — the data-quality expectations the producer commits to enforce
+- **SLAs** — service-level commitments for freshness and uptime
+- **Publisher / Personas** — who's accountable for the contract, who depends on it
+- **Glossary Terms** — the business glossary terms anchored to the contract
+- **Delivery Types** — how the data is delivered (Snowflake, Kafka, dbt, …)
+- **Lineage** — upstream sources and transformation steps
+
+Each item is a card on a 3×3 canvas. Click to add, click to edit, click to delete. The whole contract serialises to a single JSON file that lives alongside your code or in a docs repo — version-controlled, diff-able, reviewable.
+
+## How It Works
+
+Users open the app at `localhost:5119`, click **+ New Contract**, fill in the canvas areas, and the contract auto-saves to `data/<contract-name>.json`. Multiple contracts can be created and switched between via the contract dropdown. Existing contracts can be exported as JSON for sharing or imported back from a JSON file.
+
+The app ships with a starter example contract so visitors land on a populated canvas the first time they open it.
+
+## Key Benefits
+
+- **One canonical answer** — the contract lives in one place, not scattered across decks
+- **Visual structure** — the 3×3 grid makes section coverage immediately obvious
+- **Producer + consumer view** — captures both sides of the contract in one artefact
+- **JSON-native** — versionable, diff-able, fits into any docs or code repo
+- **Multiple contracts** — model different datasets in separate contracts, switch between them with one click
+- **Runs locally** — no cloud accounts, no sign-ups, your data stays on your machine
+
+The Data Contract is available now in the Context Plane monorepo at `apps/data-contract/`.

press-releases/001-odcs-alignment.md

@@ -0,0 +1,61 @@
+# Data Contract Now Speaks Bitol ODCS v3.0.2
+
+**17 April 2026**
+
+AgileDataGuides today released a major upgrade to the Data Contract app, aligning it with the [Bitol Open Data Contract Standard (ODCS) v3](https://bitol-io.github.io/open-data-contract-standard/) — a Linux Foundation project setting an emerging vendor-neutral standard for data contracts. Contracts authored in the app now export as valid ODCS v3.0.2 YAML and import the same format straight back. The release also introduces a reusable Language Framework that establishes a pattern for interoperability with other standards.
+
+## The Problem
+
+The v1 Data Contract captured contracts as a 3×3 canvas of plain name/description items. That was fine for sketching but fell short of what a real, machine-readable contract needs:
+
+- No schema field types (everything was a string)
+- No quality rule semantics (operator, threshold, target column)
+- No SLA structure (property, value, unit)
+- No team roles
+- No contract metadata (status, domain, data product, tags)
+- And no path to interchange with established standards
+
+Without typed fields and a recognised serialisation format, a contract was a document rather than a programmable artefact.
+
+## The Solution
+
+Data Contract v2.0 enriches the data model to match ODCS v3 structure and ships a Language Framework that translates the native model to/from external standards.
+
+### Enriched data model
+
+- **Columns** carry `logicalType`, `required`, `unique`, `primaryKey`, `classification`
+- **Quality Rules** have `ruleType` (completeness/uniqueness/accuracy/freshness/custom), target `column`, `operator`, `threshold`
+- **SLAs** have `property` (frequency/latency/uptime/retention), `value`, `unit`
+- **Team Members** have a `role` (owner/steward/engineer/analyst/consumer) and replace the singular Publisher
+- **Contract metadata** — status, domain, data product, tags — sits in a Tier 2b strip below the toolbar, all fields editable inline
+
+### Bidirectional ODCS YAML
+
+A new **Export ODCS** button produces valid ODCS v3.0.2 YAML. The **Import** button auto-detects YAML files (by extension or `apiVersion:` prefix) and parses them back to the native format. Round-trip tested — export → import → equivalent contract.
+
+### Language Framework
+
+The bigger idea sitting behind the ODCS work: a general-purpose Language Framework in `packages/shared/src/languages/`. The Context Plane has its own native vocabulary (`contract_model`, `dict_column`, `has_data_asset`, …). External standards — ODCS, OWL, RDF, SKOS, Snowflake Semantic — are "languages" that translate to/from that vocabulary. Each language is a single file implementing an `export()` / `import()` contract. Adding a new standard means adding one file, not scattering format-specific aliases across the schema.
+
+### Agreement tab
+
+A new **Agreement** tab renders the contract as a legal-style document — Producer commits, Consumer obligations, signature blocks — useful for circulating to non-technical stakeholders for sign-off without showing them the canvas.
+
+## How It Works
+
+The Language Framework registry maps language IDs to translator modules. Apps call `getLanguage('bitol').export(graph)` to emit YAML and `getLanguage('bitol').import(yamlString)` to parse it. Each module owns its own pure conversion code; the registry resolves at runtime so apps don't need to import every language they might need.
+
+## Migration
+
+Existing v1 contracts upgrade automatically on load. The migration runs in-place, persists back to disk, and fills sensible defaults for enriched fields (`logicalType: 'string'`, `operator: '>='`, etc.). No manual action required.
+
+## Key Benefits
+
+- **Interoperability** — export to ODCS YAML and share with any tool that reads the Bitol standard
+- **Typed fields** — column types, quality thresholds, SLA units are first-class
+- **Standards-aligned** — the metadata fields match what ODCS Fundamentals expects
+- **Backward compatible** — v1 JSON files auto-migrate, v2.0 round-trips cleanly
+- **Foundation for more standards** — the Language Framework is the path to OWL, RDF, Snowflake Semantic, and more
+- **Sign-off-ready** — the Agreement tab renders the contract as a legal document for stakeholder approval
+
+Data Contract v2.0 is available now in the Context Plane monorepo at `apps/data-contract/`.

press-releases/002-odcs-bitol-alignment.md

@@ -0,0 +1,44 @@
+# Data Contract Adds OpenMetadata Export, PROV-O Lineage, and 7-Stage Lifecycle Status
+
+**20 April 2026**
+
+AgileDataGuides today released a triple-feature update to the Data Contract app — a second export language (OpenMetadata Standards), a re-architected lineage section aligned with the W3C PROV Ontology, and the OpenMetadata Standards seven-stage lifecycle for the contract status field.
+
+## The Problem
+
+The v2.0 release brought Bitol ODCS support, but Bitol isn't the only standard data teams use. **OpenMetadata** is widely deployed in enterprise data catalogues — and it has its own JSON-based contract structure. Without an OpenMetadata language module, Data Contract users couldn't share their contracts with OpenMetadata-driven catalogues without hand-translating.
+
+The v2.0 lineage section captured upstream sources as plain items, but that hid important structure. A real lineage graph distinguishes **what** was created (entities), **how** it was created (activities), and **who** was responsible (agents) — that's the shape the W3C PROV Ontology has standardised on for over a decade.
+
+The status field was a free-text string. Different teams used different vocabularies — "live", "production", "released" — making it hard to know whether two contracts in the same status really were at the same lifecycle stage.
+
+## The Solution
+
+Three changes ship together.
+
+### OpenMetadata Standards language module
+
+A new `getLanguage('openmetadata')` translator emits and parses OpenMetadata table + quality + SLA definitions in JSON. It plugs into the same Language Framework introduced in v2.0 — no app changes needed beyond a new **Export OMS** button. Quality rules, columns, owners, and SLAs all map cleanly between the AgileData-native model and OpenMetadata's structures.
+
+### PROV-O aligned lineage
+
+Lineage items now carry a `provType` of one of three values:
+
+- **entity** — a data thing (dataset, file, report)
+- **activity** — a process / transformation / ingestion run
+- **agent** — a person, team, or service responsible for an activity
+
+`upstreamIds` references *other* lineage item IDs. The relationship label between two items is derived from the provType pairing — entity → entity = `was_derived_from`, activity → entity = `used`, activity → agent = `was_associated_with`, etc. This matches the relationship vocabulary in PROV-O exactly, so a Data Contract lineage section can be exported to any PROV-aware tool without losing information.
+
+### OpenMetadata 7-stage lifecycle status
+
+Status now uses the OpenMetadata Standards 7-stage lifecycle: **ideation → design → development → testing → production → deprecated → retired**. Click the status badge to cycle through stages. Legacy values (`draft`, `active`) auto-migrate on load (`draft` → `Design`, `active` → `Production`). The colour scheme matches the lifecycle stage so the contract's maturity is obvious at a glance.
+
+## Key Benefits
+
+- **Two-language interoperability** — export to ODCS or OpenMetadata, pick whichever your downstream catalogue speaks
+- **Lineage that round-trips** — PROV-O is the standard language for provenance; lineage data now exports to any PROV tool without lossy translation
+- **Lifecycle clarity** — every contract's status comes from a single, recognised vocabulary that consumers and auditors agree on
+- **Auto-migrating** — existing contracts pick up the new shape on load with no manual intervention
+
+The release is available now in the Context Plane monorepo at `apps/data-contract/`.

press-releases/003-openmetadata-prov-o-oms-status.md

@@ -0,0 +1,36 @@
+# Data Asset Moves to the Header, Plus RTF Export
+
+**23 April 2026**
+
+AgileDataGuides today released a structural refactor of the Data Contract canvas — the Data Asset now lives in the toolbar header instead of as a card on the canvas — alongside a new RTF export that lets users drop a Data Contract straight into Word, Pages, or any other rich-text editor.
+
+## The Problem
+
+The previous canvas layout treated the Data Asset as just another card in the 3×3 grid. That worked, but it understated how central the Data Asset is — every other section on the canvas (columns, quality rules, lineage) is *about* that one asset. Users would frequently scroll past the Data Asset card while editing schema or quality rules, then have to scroll back to confirm which asset they were even working on.
+
+For sharing contracts with non-technical stakeholders, JSON, ODCS YAML, and OpenMetadata JSON were the only export options. None of those open in Word. Users wanting to circulate a draft contract for sign-off were stuck either screenshotting the canvas or manually retyping everything into a doc.
+
+## The Solution
+
+Two related changes.
+
+### Data Asset in the header
+
+The Data Asset now sits in the Tier 2 toolbar — the same row as the contract name and description. A new **Data Asset picker widget** lets users pick from existing assets (so the same dataset can be governed by multiple contracts at different lifecycle stages) or type a new asset name to create one inline. The card on the canvas is gone; the asset name is permanently visible at the top while editing the rest of the contract, so context never gets lost while scrolling.
+
+Existing contracts auto-migrate — the v1/v2.0 `dataAsset` card moves into the header on first load.
+
+### Export RTF
+
+A new **Export RTF** button writes the contract to a Rich Text Format file that opens cleanly in Microsoft Word, Apple Pages, LibreOffice Writer, and Google Docs (via Upload). Sections render as headings, columns as a table, quality rules and SLAs as bullet lists, and the contract's status / domain / data product appear at the top as a metadata block.
+
+RTF is hand-rolled in a converter module (`src/lib/converters/rtf.ts`) so there's no dependency on a heavyweight Word library — the file is plain text with RTF control words, generated client-side.
+
+## Key Benefits
+
+- **Permanent context** — the Data Asset name is always visible while editing schema, rules, and lineage
+- **Reusable assets** — the same Data Asset can be referenced from multiple contracts (e.g. a draft and a production contract for the same table)
+- **Word-ready export** — circulate a Data Contract draft to non-technical stakeholders in a format they can read and comment on without installing anything
+- **No new dependencies** — RTF generation is pure string manipulation
+
+The release is available now in the Context Plane monorepo at `apps/data-contract/`.