Context Builder

Inspiration

Everyone says "build a context layer for AI." Nobody shows you one. What they show you instead is a proprietary silo, hand-written by whichever team drew the short straw, stale by the following Tuesday.

We work on the open standards that already describe this: ODCS for data contracts, ODPS for data products, export to OSI/Ossie for semantic models. The standards aren't the problem. Filling them in is the kind of work that makes people change careers.

Meanwhile, Cortex sits inside Snowflake, able to read your schema and sample your data and form strong opinions about both. So: let the model draft the boring parts, let a human approve them, and write the result in open standards so it's worth something outside our UI.

Try it.

What it does

Point it at a Snowflake database. Five steps later, you have a governed data product ready for AI agents.

Source. Browse the catalog: databases, schemas, tables, columns, row counts, keys. Metadata queries only. We don't read your data to populate a dropdown.
Generate. One ODPS v1.1 product plus one ODCS v3.2 contract per schema, wired together as output ports, checked against the official JSON schemas.
Analyze. Cortex profiles each table and proposes descriptions, business names, PII classifications, quality rules, and SLAs (aka Data QoS), each with a rationale. They arrive as cards you accept, edit, or reject. It does correctly spot that customer_email is PII, which is a low bar, yet.
Verify. Accepted rules compile to SQL and run against Snowflake for real: pass or fail, observed value, threshold, and the SQL itself, so you can argue with it.
Publish. Everything is saved to Snowflake as versioned artifacts that only ever grow, plus an OSI and Apache Ossie semantic model export.

How we built it

Java 21, Spring Boot 4.1.1, Maven. React 19, Vite, TypeScript. Snowflake over JDBC, Cortex through SQL AI_COMPLETE.

Everything that talks to Snowflake sits behind an interface with two implementations: the real one, and a stub Spring picks under the local profile. That's why it boots with no credentials, and why the front end can't tell the difference.

The JSON schemas bundled in the repo are the official ones. We didn't write a looser schema we could pass.

Challenges we ran into

Accomplishments that we're proud of

The loop closes. Schema, then contracts, then AI proposals, then rules that actually execute, then artifacts in Snowflake, then a semantic model export. Nobody has to squint and imagine the missing part.
Validated against the official schemas, not one we wrote to match our own output.
The human is in the loop by construction. The AI proposes, you decide, only the cards you accept get written.
It runs with no Snowflake account, and it's deployed with one at tools.actianlabs.com/contextbuilder, behind basic auth, because it browses a live catalog and spends real Cortex credits. We like you. We don't like you that much.
61 tests and a coverage gate at 60% that fails the build, on something built in a day.

What we learned

Context layers are a pipeline problem, not a documentation problem. Annoying, because documentation problems are easier. If it can't be generated, reviewed and regenerated, it rots, and the standards stay as empty as they've always been.
LLMs are genuinely good at the semantic layer: naming things, describing things, guessing a sane threshold. They are not careful enough to write straight into a governance artifact, so the validator has to be code you would trust with the model switched off.
Constraints beat prompts. Bounding profiling with SAMPLE (n ROWS) and forcing every rule into a single SELECT bought more reliability than any amount of careful prompt wording.
Open standards are the API. Because the output is ODCS, ODPS and Ossie, the tool is useful even if you never open our UI.
Cortex gotchas worth knowing on day one: no default model on the server side, no streaming over JDBC, and Cortex Analyst is only reachable over REST.

What's next for Context Builder

More sources and export. Files, streams, applications, APIs, existing metadata catalogs.
The rest of the layer. Ownership, lineage, usage, and support.
Real identities, not one shared password. Every user of the deployed tool is currently the same Snowflake service account, with its password sitting in a file. Query history shows one name doing everything, and nobody can be granted or denied anything individually.
Close the loop. Stream via Cortex REST, then point Cortex Analyst at the semantic model we just generated. Build the context, then use it, without leaving the tool.
Round trip the standards. Import contracts you already have, diff them against what the data says now, and file the difference as review cards.