Production pipelines, built by agents, approved by your team.
Connect your database and pick the KPIs you need. You get a tested pipeline, as a pull request in your repository. Your team approves it, deploys it into your cloud, and owns it.
Start from your database, and the KPIs you need.
Connect your database with a read-only login. Agents study your tables where they live and suggest KPIs that fit them. Add your own in plain words, and you are told up front if one could never return data.
Before anything is built, you can preview the design: the tables, the KPIs each one serves, and how personal data will be masked.
KPIs
- Days of stock coverYour tables
- Stockouts per storeYour tables
- Returns in EMEAYour wordsNo region is called “EMEA”, so this KPI could never return data.
A pull request in your repository, for your team to approve.
The pipeline arrives as ordinary code your team owns, tested before you see it on test data shaped like yours, never on your rows.
A person on your team approves every pull request. Deploying is a separate click, into your own cloud, and the pipeline runs there on its schedule.
- ✓Code your team owns
- ✓Tested on data shaped like yours
- ✓Personal data masked
- ✓Models documented, keys tested
- ✓Dashboards included, as code
- ApproveYour team
- DeployYour click
- RunsYour cloud
Know when it breaks, and what to do next.
Every run reports how it went, never your data rows. A run that fails, or never starts, becomes one incident with a plain-language cause and one next step, and the people you choose get an in-app alert.
The pipeline runs in your cloud on its own schedule, so it keeps running even if Nectorq is unreachable.
- Freshness
- 50htarget 24h
- Runs OK
- 28 / 30
Last 30 days
Failures began 2 days after the deploy.
Ask for a fix in plain words, and get a new pull request.
Describe the fix and it is rebuilt and tested on a copy of what shipped. It arrives as a new pull request, and production changes only when your team approves and deploys it.
A change that reshapes the pipeline, such as a different level of detail or another source, starts a new pipeline instead.
Fixes are available for Analytics & Reporting pipelines. Adding a new table or KPI to what shipped is in early access.
You asked: Days of cover should leave out closed stores.
- Fixrebuilt and tested on a copy of what shipped
- Pull request#131 Exclude closed stores from days of cover
You asked: Show one row per region instead.
↳ That reshapes the pipeline. Start a new one with the full requirement.
What you can build today, and what is on the way.
We support the databases, warehouses and clouds you already run: PostgreSQL, SQL Server, Oracle and MySQL; BigQuery, Snowflake, Databricks and Redshift; Google Cloud, AWS and Azure.
- ✓Every scheduled run succeeded
- ✓Every test passed
- ✓Warehouse totals matched the source, month by month
- Analytics & Reportingdashboards and KPIsLive
- Data Integration & Syncyour database into your warehouseEarly access
- Financial Reconciliationa table against a fileEarly access
- Intelligence & Predictionsscoring and MLComing soon
- Lineage & AuditComing soon
- Models documented, keys testedLive
- KPIs defined once, in codeLive
- Personal data masked and verifiedLive
- AI-readiness reportComing soon
- Moving off a legacy ETL tool?the agents rebuild your pipelines from your requirements, and the results are checked against the old ones with youOn request
Bring one database. Leave with a pipeline.
Start a Proof of Value on your own database. The pipeline lands in your repository, runs in your cloud, and stays yours.