Configuration document

Download a Word file that describes your project as it stands now, with a change log against the previous download.

The configuration document is a Word file (.docx) that describes how Tattva is set up for your project: the metrics it can answer, the tables it reads, the conventions and word meanings it follows, and the settings in force. Tattva writes it from the live project when you ask for it, so it always shows the project as it is at that moment. Word can save it as PDF.

Download it

Open Ontology.
Click Configuration document at the top right.
Tick Include SQL appendix if you want each metric's query at the end.
Click Download configuration document.

Any member of the project can download it. The first download can take a minute while Tattva writes the method for each metric. After that, downloads are quick unless metrics have changed.

What it contains

Section	What it shows	Where it comes from
Glossary	Each published term with its other names and meaning. Metric families come first.	Glossary terms and families
What Tattva can answer	The scope line, the example questions from your active question patterns grouped by pattern, then the metrics grouped by family, by concept, or by the table they read. With no active pattern, each metric gets one model-written example question instead.	Scope convention, question patterns, metrics
Not answered yet	Each topic the team marked Not answered yet, with the reason users are told	Conventions in the Not answered yet category
Dashboards	Each active dashboard registered in Make › Dashboards: dashboard, link, metrics, breakdowns, periods and when it refreshes	Dashboards
Data sources	For each table: description, grain, key columns, date coverage, when it was last refreshed, and which metrics use it. Uploaded documents are listed separately.	Sources, column profiles, BigQuery table metadata
Metrics	One page per published metric: description, the period it takes, how recent days are treated (settlement), rules in force, the method step by step, an example question, the date it is available from, the tables it reads, the metrics it is built from, and when it last changed	Metric definitions and rules; the method is written by a model
Conventions	Each accepted convention with its value (topics marked Not answered yet are in their own section)	Conventions
Word meanings	Metric families and what happens when a question names none, words with more than one meaning, and value mappings	Families, disambiguations, value mappings
Table connections	Verified connections between tables and the columns they match on	Links
Settings in force	Proposal switches, the answer scope (where figures may come from, which question kinds are answered), Repeat questions (whether a question a dashboard covers gets its link), tables with proposals switched off, workspace tables hidden from the project, hidden columns, personal and restricted columns, and how many members hold each level of personal-data access	Project settings and column sensitivity
Change log	What was added, removed or changed since the previous download	The snapshot stored with each download
Appendix: SQL per metric	Each metric's stored query or formula. Included only when you tick the box.	Metric definitions

Only what is in force is included: metrics and glossary terms that are published, conventions and word meanings that are accepted, and question patterns that are active.

Date coverage and last refreshed

Date coverage is the earliest and latest date in each of the table's event-time columns, taken from the column profile. The document says which day the profile was taken ("profiled on"). Re-profiling the table updates it.

Last refreshed for a BigQuery table is the time BigQuery reports the table last changed, read when the document is generated. For a view, it is the latest time among the tables under it. Reading this costs nothing: it is table metadata, not a query. For an uploaded file, it is the time of the latest upload.

Settlement

The settlement lines on each metric page use the same settlement that answers use. A metric's own settlement is stated with its number of days. A metric built from another metric that settles later inherits that settlement, and the page names the metric it comes from. Rules that apply only when the period reaches the unsettled days are listed under settlement. If the metric's query handles those days itself, the page says so.

The parts a model writes

Two parts of each metric page are written by a model from the metric's stored definition: the method, step by step and the example question. Everything else in the document comes straight from the project's stored data. The example questions under What Tattva can answer are the team's own, from active question patterns; the model-written ones are used there only when the project has no active pattern.

The text is written once for each version of a metric and kept. A metric's version covers its name, description, query, the period it takes, its settlement, its rules and the metrics it is built from. Changing any of these means the text is written again on the next download. An unchanged metric reuses the text it already has, so it costs no model call.

If the model cannot write the text for a metric, that page says so. The next download tries again.

Change log

Every download is numbered and keeps a snapshot of what the document said. The next download compares itself with the most recent snapshot and lists:

metrics, tables, conventions, table connections and settings that were added or removed;
for anything that changed, which fields changed, with the old and new values. A changed query is listed as "Query changed" without printing the SQL.

The first document for a project says that there is nothing to compare it with yet.

Personal data

The document never contains values from personal-data columns. It names the columns that are personal, restricted or hidden, but it does not show their date ranges or value mappings. The settings section gives the number of members at each level of personal-data access, not who they are.