Connect Terazu to a real estate and it drafts a lot: the tables worth modeling, how they relate, and what they mean. A draft can already answer a question, marked not certified, but nothing counts as certified until a person signs it. So the first thing a new team sees is a pile, and the first reaction is fair:

“Look at my model and my reports. Isn’t it obvious what should be certified?”

Some of it is. That’s why Terazu does the sorting, the measuring and the paperwork, and says what it would do with each item. It still doesn’t sign.

Why Terazu won’t sign for you

A certified relationship feeds every answer that crosses it. A wrong one doesn’t fail loudly. It quietly shapes numbers people act on.

  • Evidence can look perfect by accident. Two ID columns that both count up from 1 overlap completely, whether or not they’re related.
  • A BI model is someone’s assumptions, written down. Certifying it on import would copy its mistakes in bulk.
  • A certification has a name on it. When an auditor asks who owns a number, “the software decided” isn’t an answer.

So people certify, every time. What Terazu can change is how much of the work reaches them, and how little of it needs real thought.

One queue, sorted by the decision it needs

Ontology › Objects › Needs you is the queue. It lists the drafts the most-read first, each with what Terazu recommends and why, and it gathers the decisions that are the same for many items into batches done in one go:

  • Technical tables. A tool’s own bookkeeping, staging copies, key maps and leftovers. Hidden in one batch, they stay out of answers and out of the assistant’s reading, and Terazu remembers, so they don’t come back.
  • Links from joins your estate already runs, each with its evidence, measured again when a person certifies it.
  • Meanings for Objects certified with nothing said about what they are, drafted from their evidence for a person to check.
  • Business names for Objects that still carry a table’s name.

Each draft left after that gets one careful look, with the recommendation on its card: declare this one a calendar, merge these, keep that apart.

Needs you on the demo, from the recording of 14 October: Needs you 10, Certified 28, All 34. 34 Objects; 6 Objects need you, the most-read first, and 4 batches can be done in one go. In one go: Technical tables, 4 tables, Hide 4; Links, 43 joins in use, 9 ready and 34 waiting for something first, Certify 9; Meanings, 28 certified Objects, Write 28; Business names, 24 Objects, Rename 24. Below, drafts: DimCalendar, used by 2 reports, with Terazu recommends: declare its calendar role, and Certify; DimStore and Product, Review merge; PosStock, Merge 2.
On the demo, Ontology › Objects › Needs you, recorded on 14 Oct. After the first 28 certifications: four batches to do in one go, and the drafts left, the most-read first, each with what Terazu recommends.

On the demo, the first read of the estate left 36 drafts. 28 were ready for a quick yes and were certified in one go; 24 got business names in one batch and 4 technical tables were hidden in another. What was left took a person’s judgement.

One thing, several tables

A sale is often several tables: the till line where it’s born, the copy a load lands, the table answers come from, and a summary built on it. Terazu says which one answers and what each of the others is, from the loads and keys it read, and keeps a table apart when it holds something the others don’t.

Daily sales: one thing, several Objects, on the demo. In short: Daily sales answers from core.sales_daily in Meridian Analytics Warehouse; TillLines stays its own Object, because one column is only there, POSTED_AT; merged in, no Object answers for it. One row is one sales_daily_id. The table: POS.TILL_LINES, TillLines, draft, stays its own Object, unticked; landing.pos_till_lines, no Object, copied to; core.sales_daily, SalesDaily, draft, answers from; core.sales_by_channel, no Object, rolled up into. Why: landing.pos_till_lines is copied from POS.TILL_LINES by Airflow; core.sales_daily's key is copied from landing.pos_till_lines by core.sp_load_sales_daily; core.sales_by_channel is loaded from core.sales_daily.
On the demo, recorded on 14 Oct. Four tables, one sale: born in the till lines, copied by Airflow, answered from core.sales_daily, rolled up into a summary. The till lines stay their own Object, since only they hold when a line was posted.

When nothing is declared

Most estates don’t declare their keys. Tables have no primary keys and no foreign keys; the structure lives in how people use the data. So Terazu doesn’t wait for declarations.

  • Keys are measured. The agent next to your database counts a candidate column’s distinct values exactly and compares them with the rows it counted in the same read, on a table that didn’t change while it read. If exactly one column is unique, Terazu drafts the grain, such as “one row per till line”. A key a person declares, the database’s own key, or a join’s key comes first. If several columns are unique, a person picks; if none is, the draft waits for a person, who can declare its key. Measuring reads your data, so it asks once per batch.
  • Relationships come from use. Joins in your load jobs, stored procedures, views, reports and BI models, and in query history where a person has turned it on. Then they’re measured against the data: a Link is pre-ticked only when at least 85% of one side’s values are found on the other and both sides are already certified, and it’s measured again when a person approves it. A match on overlapping values alone stays a question for a person.

Every Link in the batch shows where it was found.

Links from joins in use, on the demo, recorded on 14 October: joins the estate already runs between two Objects. Each row has a tick box, the Link, what it's joined on and its evidence. For example: Comparable sales weekly to Store on store_id, a foreign key the database declares; Weekly sales to Legacy calendar on date_key, a BI model, cognos:MeridianFinance, and the query log, 1 query, 8 runs; Store to District on district_id, a declared foreign key and the query log, 1 query, 2 runs; Inventory snapshot to Product on product_id, a declared foreign key.
On the demo, Needs you › Links, recorded on 14 Oct. Each join with where it was found: a key the database declares, the finance team’s Cognos model, or the query log with how often it ran.

What people ask comes first

The pile doesn’t have to be finished to be useful. Terazu already tracks which questions people ask and what each one stands on, so the queue puts the tables behind those questions, and behind the reports that use them, at the top. A table nobody reads can wait.

Coverage on the demo: 4 of 27 questions people ask can be answered today. 15% answer now, 1 needs an Object, 18 need a Measure, 3 need a breakdown, 1 can't be answered yet. What would answer the most: Define net amount on Weekly sales, answers 2 questions, asked 19 times, then eight more. Below, the questions, each with its verdict, where it was asked and what is missing, and a Define this Measure button.
On the demo, Ontology › Coverage. 4 of the 27 questions people ask answer today, and “what would answer the most” names the next definition worth writing.

Guards against rubber-stamping

Batch approval has one real risk: saying yes without reading. The queue is built against it.

  • Nothing weak is pre-ticked. Rows with thin evidence, or a choice to make, start unticked.
  • Each batch is confirmed on its own. There is no “approve everything”, and a batch says what it will do and to how many before it runs.
  • Every item keeps its own record: who certified it, what they saw, and when.
  • A recommendation is never applied for you. It sits on the card with its reason, and a person takes it or doesn’t.

In the product, and coming

  • In the product today: drafts from evidence with Terazu’s recommendation on each, the grain drafter, key measurement, Links from the joins in use (measured before a person certifies them), Needs you ordered by what people read most, batches done in one go, a meaning’s current and legacy tables told apart, and Measures checked against their BI model and certified in one act when they give its number.
  • Being built: the evidence behind every certified Link, kept on the Link itself. Needs you already shows it before you certify one.

What Terazu never does is sign for you. It does the digging and the paperwork, so the people who own the meaning spend their time on meaning.

Keep reading Earned context Start with the numbers you already argue about What’s in the product, and what’s coming