AI Operations Copilot

Will your system actually create and change transactions in Sage 300, or only read from it? If it writes, does it write through methods Sage itself supports?

Both — it reads and, with approval, writes. It never touches Sage directly: every write goes through your own API layer, which uses the Sage-provided DLL — the same supported route your SIMS uses today.

Will every one of our existing business rules still apply — credit checks, tax, document numbering, costing, location and user permissions?

Yes. Writes execute through your existing code path, so every rule your connector and Sage enforce today continues to apply unchanged. We add checks above that path; we remove none below it.

Will anything ever be sent to a customer, posted to accounts, or changed in production without a named person on our side approving it first?

No. Nothing in the pilot is customer-facing, and every write action ships in approval-required mode. A fully-automatic mode exists, but only you can enable it, per action, and you can revert it at any time.

Can we set each action to read-only, draft-only, approval-required or fully automatic, and change that ourselves later?

Yes — from the admin console, per action, effective immediately, with every change logged.

Is there a single emergency stop that halts all automated write actions immediately?

Yes. One control halts all writes at once. Read-only queries can continue or halt too — your choice.

Will calculations that must be exact — FIFO allocation, pricing, label selection — run on fixed programmed rules rather than an AI model deciding each time?

Yes, and stronger than you asked: they are not recalculated by us at all. FIFO, tax and pricing execute in your existing SIMS logic through your endpoints. The AI model's only job is understanding the instruction; deterministic code does everything after that. (Label selection is not in the pilot; the same principle will apply when it is.)

What happens when the AI gets something wrong? Who carries responsibility for a wrong accounting entry, a wrong stock movement or a duplicate invoice caused by your implementation?

The AI can only propose; a wrong proposal is caught at the confirm-echo and approval step, before anything posts. If a defect in the layer we build causes a wrong or duplicate transaction despite a correctly approved instruction, that is our defect — we fix it at no cost under warranty and assist with reversal. The full boundary is written out in Section 7.

Can you guarantee that a retry, a timeout or a network failure will never create a duplicate transaction?

Within our layer, yes — every write carries an idempotency key, so a retried action cannot post twice from our side. End-to-end, the transaction also passes through your connector and Sage; total-system safety is proven jointly in the test plan, where we deliberately interrupt transactions on the test server and show you the outcome. We will not claim a unilateral guarantee over code we did not write.

Will every automated action be recorded — who or what did it, what was approved, which document number resulted, and the final status?

Yes: initiator, instruction text, resolved entities, approver, resulting document number, final status, and timestamps for each step.

Can we export those records ourselves for our auditors, without asking you?

Yes. The audit log lives in your SQL Server; export to CSV or Excel from the console at any time.

Which of our data would leave our network, and where would it go?

Only the instruction text and the minimum context needed to resolve it goes to the AI provider's API over an encrypted connection. Application data, documents and drawings do not leave. The copilot services and the audit log run in your environment.

Which AI providers would see our customer names, prices, order values and drawings?

Your choice from the options in Section 6 TO DECIDE — JC · named list. Drawings are not part of the pilot and are sent to no one. With masking enabled, customer names and prices are replaced by internal identifiers before any text leaves your network. One thing we say plainly rather than hide: order quantities appear in the instruction itself ("commit 5,000") — that is inherent to the command, and it is the only order-value data the model sees.

Would our data be retained by those providers, or used to train their models?

We only propose providers whose enterprise terms exclude training on customer data and offer zero or strictly limited retention. The written terms are included with the provider options.

Can sensitive information be masked before it is sent out, and can some workflows run entirely inside our own network?

Yes to both. Masking is described above; saved queries, reports, the audit log and the admin console run entirely on your network with zero AI usage.

Where would our data physically be stored, and can we choose the location?

Application and audit data: on your servers, alongside your existing SQL Server databases. AI processing location depends on the provider and region you choose from the options presented.

How would our passwords, Sage credentials and server credentials be stored and protected?

We never receive your Sage or server credentials — they stay inside your connector and environment, as today. The copilot authenticates to your API layer with credentials you issue and can revoke, held in a secrets vault in your environment, never in code or repositories.

Would you carry out security testing before we go live, and would we see the findings?

Yes — over the components we deliver, before production, with findings shared in writing. Scope in Section 6.

Do we own the accounts, environments, source code and any connectors you build, from day one and not at the end?

Yes. Repositories are created under APL's account on day one and we work inside them. Cloud or provider accounts are opened in APL's name.

Would the code sit in repositories that belong to us?

Yes — from the first commit.

If the relationship ends, can our own team or another vendor continue the work without you? What exactly would we be holding?

Everything needed to continue: source code, deployment scripts, configuration, documentation, the runbook, the audit database, and your provider accounts and keys. The stack is chosen for maintainability by a team like yours ESTIMATION · confirm stack statement.

If you modify our existing connector or our SIMS code, who owns the modified version?

The pilot is designed not to modify your code — we call your endpoints. If a gap requires changes on your side, your team builds them to a joint specification, or we build them as work-for-hire owned by APL. Either way, the modified version is yours.

What is the one-time implementation cost, and what specifically sits inside it?

Section 8: a fixed Phase 0 fee, and an indicative pilot fee made binding at the Phase 0 gate. It covers the four capabilities, the admin console, audit, testing, documentation and training listed in Section 4.

What will it cost us every month to run — AI usage, voice, servers, storage, backup, licences and support? Low, expected and high case.

Section 8 table: ₹35,000 / ₹50,000 / ₹75,000 per month PROPOSED, plus AI usage at cost on your keys (estimated ₹2,500–9,000 per month at the stated volume assumptions). Voice is a later phase and carries no cost in the pilot. Storage and backup ride your existing SQL Server routine.

What is the running cost per order, per shipment, per invoice, per label and per price update?

For the pilot's actions we give assumption-based ranges in Section 8 — and the pilot meters the real per-action cost by workflow, so you hold measured numbers before any rollout. Invoices, labels and price updates are not in the pilot; their costs will be quoted with measured pilot data behind them.

Can we set a monthly budget, a hard ceiling and cost alerts, and see cost by department and workflow?

Yes — all four, from the admin console. At the hard ceiling, AI calls stop and everything else continues.

Which parts will consume AI usage every time they run, and which will run as ordinary software at no per-use cost?

AI usage: understanding a typed instruction, once per instruction. Ordinary software: everything else — confirm-echo rendering, approvals, execution calls, audit, reports, saved queries, the admin console.

Which costs are not in your proposal and would fall on us?

Listed in Section 8: AI provider usage on your keys, your server capacity, and any third-party licences (none anticipated for the pilot).

What circumstances would lead to charges beyond your quoted price?

Only scope you approve in writing beforehand — new capabilities, endpoints we build on your behalf under the build-split rule, or volumes materially beyond the stated assumptions. Nothing else.

If our internet fails, or the AI provider is down, or our usage budget is exhausted, does our invoicing, dispatch and stock work continue?

Yes — completely. The copilot is an additional layer over systems it does not modify. If it is off for any reason, your team uses the SIMS dashboards exactly as they do today. Nothing in your current flow depends on our layer.

Can we change AI provider later without you rebuilding the integrations?

Yes. The provider sits behind an abstraction; switching is configuration plus a re-validation pass of instruction understanding — not re-integration.

What happens when Sage 300 is upgraded, or when our e-invoice vendor changes their software?

A Sage upgrade lands on your connector — as it does today — not on the copilot, which sits above your API layer. You have lived this once: a Sage upgrade removed the connector service you depended on, and your team rebuilt it. That category of risk stays where it has always been — in the connector layer, which remains yours and unchanged — not in the copilot above it. If your API contract is unchanged, the copilot is unaffected; if it changes, the adjustment is at the integration seam, the smallest part of the system. The e-invoice chain is not part of the pilot.

What is your recovery position — how quickly are we back up, and how much work would we lose?

State and audit live in your SQL Server under your existing backup routine; the services are stateless and redeploy from your repositories. Target recovery time: same business day, within 8 hours PROPOSED. Approved-but-unexecuted actions are queued durably and are not lost.

How many of our engineers do you need, with what skills, and for how many hours a week?

Two people, part-time: Gurvir approximately 6–8 hours per week (endpoints, access, technical questions) and Yogesh approximately 3–4 hours per week (validation sessions) PROPOSED. No other APL staff are needed until user training.

Which parts would you build, and which parts do you expect us to build?

We build everything above your API layer: the AI layer, control layer, console, channels, audit. You provide the endpoints your rebuild already exposes. Missing endpoints follow the build-split rule in Section 9 — decided case by case at Phase 0, in writing.

Will our existing SIMS keep running while this is being implemented?

Yes — untouched. Development happens against your test server.

Does the new system replace SIMS completely, replace some modules, or run alongside it?

Alongside. It replaces nothing — not SIMS, not the dashboards, not your connector. That is a design decision, not a limitation.

Will our staff have to learn a new application, or does this reach them inside what they already use?

Inside what they use: a copilot panel embedded in your SIMS web interface, plus an optional chat channel for management. There is no new application to learn; there is one new panel and plain language.

What training and documentation do we receive, and for whom?

User guide and hands-on session for dashboard users (up to 15 people PROPOSED); admin guide for whoever owns modes, budgets and approvals; operations runbook for your IT team.

Can you demonstrate a real transaction going into a Sage test environment, and a clean rollback when it fails, before we approve production?

Yes — it is a scheduled milestone, not a favour: the midpoint of Phase 2, demonstrated live to your team, before the balance payment is due.

Will you provide a written test plan covering failures, duplicates, interruptions and simultaneous users, not only the happy path?

Yes. The test plan is a deliverable, executed jointly on your test server, including deliberately interrupted transactions and concurrent operations alongside native Sage users.

Will you test on our own representative data before go-live?

Yes — on the test server and sample data you provide. Instruction-understanding accuracy is measured on your real item codes and order patterns.

Can you show us a comparable implementation you have already put into production?

Partly, and we will be straight about it. We run AI agent systems in production — our Clonify platform, a customer-service automation handling live scheduling operations, and voice agents — and we have been building software for over ten years. We have not yet put an AI write-path into Sage 300 specifically. That is exactly why this proposal is a small paid pilot with proof gates rather than a large commitment: the midpoint demonstration on your own systems is the evidence, before your balance payment.

What warranty applies after go-live, and which defects do you fix at no cost?

60 days after go-live PROPOSED — JC to confirm, covering all defects in the delivered scope at no cost, per the responsibility boundary in Section 7.