Security and data handling

Every external email — the RFQ invitation, an addendum, a chase reminder, the covering note on a purchase order — is written into a staged-email record and left queued. A person opens the draft, reads it, edits it if they want, and clicks Send. Nish holds no tool that transmits to a vendor; the tool it does hold explicitly refuses to send and says so in its own description.

Raising a case, approving the budget against a budget head, awarding the order and approving the purchase order are four decisions taken by named people, routed by your approval policy and its value bands. There is no auto-award setting, so there is nothing to leave switched on by mistake.

Each tool call is written as its own row carrying your organisation, the person who asked for it, the tool, the arguments it ran with, the result it returned, its status and the timestamp — and, if it was undone, when. The record is per-organisation and indexed by time, so “who changed this and when” is a query, not an investigation.

The comparison engine is ordinary code. Normalisation runs in a fixed order — unit basis first, then freight allocated across lines by value, then the vendor’s offered credit priced at your cost of capital, then GST treatment — because each step compounds on the one before it. Run it twice on the same quotes and you get the same ranking, the same evaluated totals and the same L1.

A quote that does not state its payment terms produces a gap to chase the vendor about, never an assumed number. A GST rate that differs from your organisation’s norm is flagged for a human, and the rate the vendor actually stated is the one that applies. Lines the case never asked for do not silently enter a ranking.

A model is used to read a supplier’s PDF or email into structured quote lines, and to write prose — RFQ text, an email draft, a summary. Once a line is structured, every rupee after that is arithmetic in code. Drafts are for your team to check against the supplier’s original document, which always governs over our summary of it.

Vendors, items, price points, budget heads, rate bases, playbook versions and rows, purchase cases, RFQs, invited vendors, vendor quotes, quote lines, comparison decks, cost sheets, purchase orders, deviation records, agent threads, agent messages, agent tool calls, staged emails, email logs and action tokens all carry the owning organisation as a column, and are read back through that scope.

The list of organisation-owned models is declared in one file and asserted by a test in the same directory. Adding a table to the schema without placing it in an ownership bucket fails that test, so the isolation rule is enforced at build time rather than by code review.

The operation wrapper resolves the caller’s organisation and role from their server-side session before any handler runs, and the handler receives that context. An organisation identifier supplied in a request body is not what a query is scoped by.

A person holds one of three seats. A purchaser runs the desk. A finance approver decides budgets and purchase orders and manages approval policy. A requester raises and tracks their own requests, answers technical questions on their own case and confirms receipt — and that is all. The capabilities of each seat come from a single table, so what the agent offers, what its help lists and what the server will actually run cannot drift apart.

Whatever is proposed, a caller can only execute the tools their seat holds; the check runs ahead of argument parsing and returns a plain refusal. Ask “where is my bearing order?” as a requester and you get the stage and the dates. The prices are not redacted out of the answer — they are not fetched for that seat, so they never reach the wire.

Every line on a cost sheet declares where its number came from: an earlier cost sheet, a commodity index anchor, your organisation’s own rate basis, or a stated assumption. A comparison line points back to the supplier’s quote line it was computed from.

Where the engine had no precedent it says so, marks the line as an assumption, and widens the confidence band accordingly. The sheet reports how many assumptions are still open so nobody signs one without noticing. When a person puts a real number on a line, the generated provenance comes off with it — the sheet does not keep claiming a source that no longer describes the figure.

You send us the people and the seat each of them should hold, and we seed those accounts. A stranger who finds the login page cannot create one, and an unknown address cannot bootstrap itself into your organisation. Sign-in is Google OAuth or work email and password, whichever your IT prefers.

A password is never stored. What is stored is a scrypt-derived key with a random per-user salt, compared in constant time on every sign-in, and repeated failed attempts against an address are throttled.

Sessions are rows in the database, not self-contained tokens, so deleting one ends that session on the next request rather than waiting for a token to expire. In production the session cookie carries the browser-enforced __Secure- prefix and is restricted to same-site navigations.

Programmatic access uses bearer tokens that are hashed with a server-side secret before storage — the raw token is shown once and never held. Each token carries explicit scopes, belongs to one person in one organisation, expires (ninety days by default, a year at most), and can be revoked. Every call made with one is written to the same per-organisation audit record as any other action.

Responses are served with content-type sniffing disabled, framing denied outright, and a strict cross-origin referrer policy.