Grouped by what you're actually asking. The last section — honest limits — always stays last: the other answers are trustworthy because it exists.
A free analysis of how your quoting actually behaves. You send us a quotation export from your system; you get back a report on the value sitting in quotes nobody decided on, where the same item left at different prices, how differently your team discounts, and how your response time tracks against what you close — plus what your data couldn't tell us and the column that would fix it. Every figure is computed from your own rows, and every "we can't tell" is said plainly. Three business days from the file arriving. There are 3–5 slots for design partners.
A quotation export from your system, in any format your system produces (CSV, Excel, PDF list). No API access, no login sharing, no account setup. Email partners@pruvato.com and we'll take it from there.
No cost. The "catch," said plainly: we want to work with a small number of businesses closely, in a specific market segment, at a specific stage. If that's you, we get a customer and you get your quoting workflow improved and automated; if it's not, you get a useful report and nobody's time is wasted.
Nothing automatic. If the report is useful and you want to see governed execution on live quotes, that's a separate conversation. If not, the report is yours; we don't follow up.
The AI proposes — it reads your customer's request and drafts line items. It never touches your Zoho, holds no credentials, and can't send anything. A separate deterministic engine executes the plan against your declared rules; a person approves the exact version; a read-only account then reads your books to confirm the result. The AI has no hands.
No. Every value used comes from a real source — your customer's message, or your own catalogue. If a price isn't in your list or an item can't be identified, the run stops and asks rather than picking the closest match.
It can create draft estimates and read your books. It cannot send quotes to customers, mark things accepted, change customer records, touch invoices or payments, or modify anything you didn't approve.
It stops, on a specific line, and shows you a compact decision: what was expected, what it found, what the difference means. Nothing progresses until you rule on it. Your ruling — with the reason you gave — goes on the record beside the problem, permanently.
You decide, in your rules. Above your declared thresholds, a specific named person approves each time. Below them, a rule can pre-authorise (with the pre-authorisation itself journaled). Approval is always tied to the exact version being approved — change a line afterwards, and the approval no longer covers it.
Your commercial values never enter our permanent record. They live in an evidence store, under a retention policy you set — and when you remove them, the removal is itself recorded. What remains permanently is what an auditor needs to check the work: fingerprints, verdicts, times, identities. Nothing you'd mind an outsider seeing.
No — that sentence is more comfortable than it is true for our category. We do retain what makes proof possible; we refuse to retain what would only be liability. A receipt an auditor can re-check against your books requires remembering which books and which record; retaining nothing at all would mean "we ran a check" is the only claim we could make, when the whole point is "you can redo the check." We're a verification-first company, not a privacy-first one, and the difference is honest.
The application runs in the UAE region. Two categories of third party are involved by necessity and named: your accounting provider (Zoho — because it's your system of record) and the AI model provider we use for parsing. Neither sees more than they need to; the AI provider sees the customer's message text at parse time and no historical data.
Everything in the evidence store can be exported or deleted at your instruction; the deletion is itself a recorded event, so you can prove the removal happened. The permanent record — which contains no commercial values — is retained per your retention policy.
Yes. Every run has a receipt page you can open, showing what happened, what was checked, what was approved, and what was verified — in plain language.
No. An AI agent decides what to do and then does it, with its own credentials. Here, the AI proposes; something else executes, under rules you set. When agent stacks fail, it's usually because the deciding-and-doing were the same thing. Separating them is what makes governed execution.
Testing shows an AI behaves correctly in a lab. Governed execution controls what happens when an AI meets your real systems. Both are useful; neither replaces the other. If an AI passes every test and then a novel case appears in production, the test doesn't help you — the enforcement in the execution path does.
Logs record what happened. Monitoring watches it. Neither prevents a wrong action — they tell you about it afterwards. Governed execution makes the wrong action structurally unable to occur: a below-floor quote isn't flagged, it can't be sent. A missing step isn't detected after, it can't be skipped.
Signed records prove the record wasn't changed since sealing. That's real and useful. What they don't prove is that the recorded work was right. A signed record of an AI's claim about what it did is still an AI's claim, sealed. Our receipt records what an independent read of your own books found, so the receipt survives being asked "yes, but was it right?"
Two systems trained on similar data share failure modes. They agree fluently. Agreement is not verification. Our verifier is a deterministic program comparing values against your system of record — it cannot be prompted, persuaded, or talked around.
This section always renders. If it doesn't, the rest of this FAQ shouldn't be trusted either.
Because determinism ends at our boundary. We can send Zoho a perfect request and Zoho can still fail, half-apply, or report success incorrectly. And once a record exists, other people and other tools can edit it directly — that's outside our control, correctly. Verification is what catches the difference between "we said we did it" and "your books actually show it."
Yes. That's why the read-back exists — a separate identity your own accounting provider will not let write, reading your own books, producing evidence your accountant can check without trusting us. And we go one rung further: an internal instrument certifies the verifier itself, because our name is staked on the honesty of the check. Eventually the goal is that the receipt is checkable by anyone the customer authorises, without going through us at all.
No. A value can genuinely come from your customer's message and still be the wrong business decision. Grounding prevents inventions; it doesn't replace judgment. That's why a person sees the facts before approving above your thresholds, not just a green light.
You can, always — no vendor should be able to stop you editing your own books. What we do is catch the change on the next read-back: the receipt will show the difference between what you approved and what your books now say, on the specific field that changed, so you can decide. Prevented is impossible outside our path. Detected isn't.
No execution architecture reaches other tools using the same credentials. That's why grants are per-connection, why the writing identity here has a specific ceiling, and why the receipt identifies what this system did — so a change made by another tool shows up as a difference between your approval and your books, exactly like a manual edit.
The interesting question, and asked in good faith. Two categories: mistakes in our own deterministic code (which is why we invest heavily in checks that must prove they can fail, and independent measurement of our verifier), and misconfigured rules on your side (a rule written more permissively than intended will do exactly what it says — governed execution enforces rules faithfully, not wisely). Both are why setup with a design partner is concierge-heavy in this phase, and why we recommend rules be reviewed with someone from our side before they go live.