In Step 1, Maxa extracts concrete figures from your inputs - the revenue total from an investor deck, the customer count from the CFO transcript. Those numbers become the acceptance criteria. Step 2 isn't done until the pipeline returns those exact figures.

So "correct" means: net revenue for Q3 comes back at $847M, intercompany rows excluded, fiscal period boundaries right. Not "the SQL ran without errors." There's a difference.

Every model also ships with generated tests - row-count parity, key integrity, event structure, source traceability. If something breaks silently, a test catches it.

No. You export your table schemas and a sample of rows - up to 10,000 per table. That gets loaded into a local database inside your Maxa environment. All agent work runs against that local copy. Maxa never connects to your live warehouse, never queries production.

Read-only access is enforced at the database level. When Maxa is done, you download a dbt project and deploy it yourself, in your own warehouse.

For standard modules - SAP FI/SD, Oracle Financials, D365 Finance - the knowledge library already knows where invoices live and which joins are safe. Discovery confirms what it expects rather than searching blind.

For customizations, discovery searches your actual data using the concrete entity examples from your spec - your customer IDs, your invoice numbers. It finds the right tables regardless of what they're named.

Where it needs your help: when a customization changes the logic, not just the table names. Those are the steering moments where your judgment matters. Maxa surfaces them for review rather than guessing.

Yes. It's a standard dbt project - models, tests, sources. You download it, put it in version control, and run it yourself, with no dependency on Maxa's infrastructure to execute.

You can add models, modify existing ones, and ref Maxa-generated models from your own the same way you'd ref anything else in dbt. What you get is readable SQL you can open, understand, and change.

An LLM writes plausible SQL - it has no way to know if the output is actually correct. Maxa runs the model against your data, checks the result against the numbers from your spec, and iterates if there's a gap. It's not generating SQL and hoping - it finds the $16M discrepancy, fixes the FX rule, and runs again until the number is right.

The other difference is structure. An LLM writes you a query. Maxa builds a layered pipeline where every business rule is versioned and auditable. That's the difference between SQL that works today and a pipeline that's maintainable in a year.

They always do. Companies merge, product lines get retired, the CFO changes how FX is calculated.

In a Maxa pipeline, harmonization rules are versioned. You update the rule in plain language, Maxa regenerates the affected layer, and the old version is preserved with a timestamp. The change is auditable, and you can re-run validation against your original spec to confirm nothing else broke.

It depends on complexity, but the bottleneck shifts completely.

The spec phase - requirements extraction, stakeholder alignment - compresses to a day or two once you have the materials. The build phase depends on how many source systems are involved. A single-source mart can be in production within a week. Multi-ERP harmonization across SAP, Salesforce, and Workday takes longer, but we're talking weeks, not months.

The first project is always slower. The second is much faster - the library already knows your systems.

Yes. The most common pattern: Maxa's models live in a separate folder within your dbt project, and your existing models ref them the same way they'd ref anything else.

If you have models that overlap with what Maxa generates, you can migrate them gradually, keep them in parallel, or leave them alone. No flag day.

It's not a replacement for your team or your existing project - it adds a harmonized foundation layer that your existing work can build on top of.