Library

​

What it does

The Library is where your organization’s shared understanding of its data lives: what your columns mean, how your tables relate, how your metrics are calculated, and which queries are trusted. Approval is what makes a definition count. Only approved definitions are used to answer questions, so anything still suggested, rejected, disabled, or broken is never treated as authoritative. That is what keeps results consistent and defensible.

​

What it holds

• Metrics, named measures with their computation and filters
• Tables, reusable sets of rows that metrics are built on
• Column meanings, what a specific column represents and how it should be treated
• Relationships, how two tables join together, with match quality
• Value maps, how values in one system correspond to values in another
• Saved queries, approved queries for a specific business question

​

Getting around

The Library has its own navigation down the left. Overview is where you land. It shows the state of your library at a glance: how much of your data is covered, how many definitions are approved, how many are waiting on review, and how many have broken. Below that, Needs attention lists what is worth handling now, Pick up where you left off returns you to any unfinished drafts, and Recent activity shows who approved, rejected, or suggested what. Review is your queue of decisions, with a count of what is waiting. Browse lets you work through everything, either all definitions at once or one kind at a time, with filters for status, source, and connection. Rejected and disabled definitions are tucked away by default, and Show dismissed brings them back. The search box at the top searches your whole library.

​

The review inbox

Review is split into three tabs. Suggestions are new definitions waiting for a decision. Work down the list and approve or reject each one, using the arrow keys to move between them. Drift breaks are metrics that stopped matching your data. A metric lands here when its numbers no longer reconcile, or when another metric it depends on was un-approved. Either way it is excluded from answers until you look at it. This is the one to watch, because it is how you find out something quietly stopped being trustworthy. Conflicts are questions people actually asked that Pluvo could not answer from your approved definitions. Each shows the question, whether Pluvo declined to answer or answered without verified figures, and how often it has come up. They are the best available reading of what your library is still missing.

​

Making a decision

Approve puts a definition to work. Reject marks it wrong, and Pluvo will not suggest it again. Disable takes something out of use without saying it was wrong. Rejecting asks for an optional reason. It is worth writing one, because it appears alongside the decision later and saves the next person wondering why. All three decisions are reversible. Click an applied decision again to undo it, and the definition returns to suggested.

​

Creating a metric

Definitions arrive on their own as Pluvo learns from your data, but you can also build a metric yourself.

​

Tables

A Table is a reusable set of rows that your organization has agreed on, defined once and then used as the foundation for metrics. Rather than every metric working out which rows count from raw data, you define the shape once, check it, and build on it. Each Table carries a plain-language contract: what a single row represents, how dates are handled, which columns are safe to group or filter by, and what each column means.

​

Building one

Tables are created through the same Create definition conversation. Describe the rows you need, for example a monthly revenue-by-customer table, and Pluvo drafts one for you. The draft appears in a panel where you can work through it.

​

Using a Table for a metric

Once a Table is published, it becomes a source you can build metrics on. In the builder, choose it from Library Tables rather than picking raw connected data, and Pluvo offers only the calculations and breakdowns its contract allows. That is the point: the Table has already settled which rows count, so the metric only has to say what to do with them.

​

Reading a metric

Open any metric and you get the full picture across three tabs. Overview explains the metric. How it’s computed walks through the calculation in plain language, step by step. What it means gives the description and any guidance that shapes how Pluvo uses it. Source and lineage shows which connection, tables, and joins it draws on. What depends on this lists the other metrics built on top of it, so you can see what you would affect by changing it. Checked against your data is the trust check, showing the total to date against the expected value, the difference, and when it was last checked. Where it’s used shows the questions where the metric actually got used, with the value it produced, who asked, and when. It is the quickest way to tell whether a definition is earning its keep. History is a timeline of what happened to the metric: when it was created, when the formula or naming changed, when its status changed, and when it broke.

​

Previewing the data

Metrics and saved queries have a Run query button that returns the actual rows behind the definition. You can sort and filter across the full result and see per-column totals, which is the quickest way to catch a definition that looks right but is not.

​

Where definitions come from

Definitions reach your Library four ways: Pluvo discovers them from your connected data, they come from a catalog of common definitions, someone promotes a query out of an Assistant conversation, or someone writes one directly in the builder. When the Assistant produces a figure you trust, you can save its query to the Library so future answers reuse the same approved logic. Saved that way it arrives already approved, since choosing to save it is the approval. Answers that draw on Library content say so, and link back to the definitions they used.

​

Tips