Your first 30 days.
What a Dataring POC looks like, what it asks of your team, and what you keep.
What it asks of your team
About two hours of one engineer’s time, then 30 minutes a week. The two hours are the setup, on a call with us. The 30 minutes are a weekly call to review what Dataring found and what it proposes. There is no other standing commitment on your team.
The access is read-only scopes on your warehouse, your catalog and your orchestrator, plus one optional write token on your catalog, scoped to descriptions, tags, owners, importance and classification. You decide whether to grant the write token for the POC. The exact scopes, and why each is needed, are on the security and deployment page.
The paperwork is a mutual NDA and a DPA, both signed before day one.
Before day one
Three things happen between the first call and the start of the POC. We sign the NDA and the DPA. You choose the cloud account Dataring runs in, on Google Cloud, AWS or Azure. And you decide whether to grant the catalog write token for the POC, or to keep Dataring read-only until you have seen what it proposes.
If you do not run a catalog, Dataring deploys one in your account as part of setup. From the first conversation to day one takes about two weeks.
The 30 days, week by week
Thirty days, one call a week
Every week ends with the 30-minute call. That call is where you see what Dataring found, ask what you want, and decide what happens next.
Week 1: connect and map
Dataring connects to your warehouse, your catalog and your orchestrator and starts mapping every source, pipeline, table and dashboard, with lineage end to end. Your engineer spends about two hours on the setup call, granting the read-only scopes and confirming the systems Dataring connects to. By the end of the week you can see a first draft of the map covering your main systems. The map is completed in week 2.
Week 2: who reads what
Dataring reads the access logs and attaches to each table who reads it and how often. Your team confirms table owners and names the outputs that reach a regulator, auditor or customer. By the end of the week you can see who reads each table and how often, attached to the map.
Week 3: what matters and what to change
Dataring works out what the business depends on from how the data is used, and drafts its proposals: pipelines to retire, schedules to change, pipelines that deserve priority. Your team reviews the importance ranking and reacts to the first proposals. By the end of the week you can see the importance ranking and the first proposals, with the evidence attached.
Week 4: readout
Dataring prepares the readout. Your team reviews the map, the ranking and the proposals, and decides which proposals, if any, to accept. Accepted changes are applied after the readout and logged with what was done and why. The readout is a meeting, a document that carries the map and the ranking, and a view in the console.
What you have at day 30
Two things, in your account. The estate map, with lineage end to end from every source through every pipeline and table to every dashboard. And an importance ranking: what the business depends on, worked out from how the data is actually used. Any retirements and schedule changes Dataring found are proposals with the evidence attached, and nothing is applied until your team accepts it.
What you keep
The map, two ways. The readout document carries the map and the importance ranking, and before Dataring is uninstalled it exports the map as JSON or CSV into your account, the same way as the action log. That holds whether or not you granted the write token. What Dataring wrote into your catalog stays there too: if you granted the write token, the descriptions, tags, owners, importance and classification it wrote are entries in your catalog, like any entry your team typed. They belong to you. Nothing about them depends on Dataring staying installed.
After day 30
You and Dataring decide together what comes next. There is no commitment at day 30, no auto-renewal and no commercial term attached to the POC. If you stop, Dataring exports the map into your account, the cleanup script removes the deployment and its storage, and what was written into your catalog stays. The exact steps are under When you stop on the security page.
Questions before you start
Do we need a catalog first?
No. If you run one, Dataring connects to it and starts from what it already holds. If you don’t, Dataring deploys one in your account as part of setup.
Which warehouses work?
Any warehouse, strongest on BigQuery. Tell us what you run on the first call and we will say what you will see on it.
Will Dataring change anything in production?
Not without your team. Schedule changes, scheduler priority and pipeline retirement are proposals in a POC, with the evidence attached, and nothing is applied until your team accepts it. The only thing Dataring writes during the POC is descriptions, tags, owners, importance and classification into your catalog, each accepted by your team first, and only if you grant the write token.
What if we don’t grant the catalog write token?
Dataring stays read-only. You still get the map and the importance ranking, and every proposal is still logged with what Dataring found and why.
Who on our side needs to be involved?
One engineer for the two-hour setup, and whoever you want on the weekly 30-minute call. Nobody else needs to change how they work during the POC.
What happens to the map if we stop?
You keep it. Before uninstall, Dataring exports the map as JSON or CSV into your account, and the readout document already carries the map and the ranking. What was written into your catalog stays: descriptions, tags, owners, importance and classification are yours. The cleanup script then removes the Dataring deployment and its storage; export the action log first if you want it.
Start the conversation
Tell us what you run and we will tell you what the first 30 days look like on your estate. Bring your security questionnaire if you have one.