Maxa extracts concrete figures from your inputs, like net revenue from the investor deck or customer count from the CFO transcript. Those numbers become the acceptance criteria. The pipeline isn't done until it returns them exactly: Q3 net revenue at $847M, intercompany rows excluded, fiscal period boundaries matched. "Correct" means the numbers match, not that the SQL ran without errors. Every model also ships with generated tests: row-count parity, key integrity, event structure, and source traceability. If something breaks silently, a test catches it.

No. You export your schemas and a sample of rows — up to 10,000 per table — into a local database inside your Maxa environment. All agent work runs against that copy. Maxa never connects to your warehouse, never queries production. Read-only is enforced at the database level. When the build is done, you download the dbt project and deploy it yourself, in your own warehouse.

Yes, with the right honesty about boundaries.

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; it doesn't search blind. For your customizations, discovery searches your actual data using the concrete entities from your spec, such as your customer IDs, your invoice numbers. It finds the right tables regardless of what they're named. Where it needs you: when a customization changes the logic, not just the table names. Maxa surfaces those moments for review rather than guessing.

Yes. It's a standard dbt project: models, tests, sources. Download it, put it in version control, run it yourself. No dependency on Maxa's infrastructure to execute. Add models. Modify existing ones. ref Maxa-generated models the same way you'd ref anything else. Readable SQL you can open, understand, and change.

An LLM writes plausible SQL. It has no way to know if the output is correct.

Maxa runs the model against your data, checks the result against the numbers from your spec, and iterates until the gap closes. It finds the $16M discrepancy, fixes the FX rule, runs again until the number is right, rather than generate-and-hope. The other difference is structure. An LLM writes you a query. Maxa builds a layered pipeline where every business rule is versioned and auditable. The difference between SQL that works today and a pipeline that's still maintainable in a year.

Companies merge, product lines get retired, the CFO changes how FX is calculated. It happens! Harmonization rules in your pipeline are versioned. Update a rule, and Maxa regenerates the affected layer while preserving the previous version with a timestamp for auditability. Re-run validation against your original business facts to confirm the rest of the pipeline still holds.

The spec phase (requirements extraction, stakeholder alignment) compresses to a day or two once you have the materials. A single-source mart: in production within a week. Multi-ERP harmonization across SAP, Salesforce, and Workday: longer, but weeks, not months. The first project is always slower. The second is much faster since the library already knows your systems.

Yes. Maxa's models live in a separate folder inside your dbt project and your existing models ref them like anything else. If you have models that overlap with what Maxa generates, migrate gradually, keep them in parallel, or leave them alone. Maxa is a harmonized foundation layer your existing work builds on top of.