Skip to content

SIMULATION LAYER 01 / 05

You are handing over your general ledger. Here is exactly what happens to it.

Financial data is the most sensitive export a company has, and a security page full of adjectives is worth nothing. Below is what is enforced in code, what is a stated posture, and what we have not yet proven. The third list is not empty, and we would rather publish it than be asked about it later.

SIMULATION LAYER 02 / 05

Enforced in code

Constraints that fail a build, not a checklist.

  • A credential that can write is refused

    The connector layer verifies that a credential cannot write to your system, and refuses to save it if it can. Read-only is checked at the moment of storage rather than promised in documentation.

    Connectors are not built yet. The rule is designed in before the first one ships, because retrofitting it later means auditing every integration.

  • The engine cannot creep in

    One module touches the vendored engine, and every import in it is function-local. Starting the API does not load a machine-learning stack. This is enforced three ways, including an import test run with the vendored tree renamed away.

    A narrow seam is a security property as much as an architectural one: it is the list of places a model can see your data.

  • The vendored engine is a mirror, not a fork

    It is a read-only copy of the platform monorepo. An in-place edit fails a blocking drift gate in CI. Divergence is allowed only by moving the file out of the mirror and recording it.

    Which means an unreviewed change cannot appear in the code that reads your figures.

  • One place for tokens and retries

    Every read from the browser goes through a single request layer: the bearer token, a single-flight refresh, rate-limit handling and conditional requests are implemented once rather than per screen.

    Duplicated auth logic is how a screen ends up quietly reading without a token.

  • Confirmed email, enforced our side

    Sign-in runs through a hosted identity provider, and the API enforces email confirmation regardless of how the provider is configured. An unconfirmed account cannot read a figure.

    A local password provider stays available so the product is never dependent on a single vendor being reachable.

  • Migrations own the schema

    The database shape is defined by migrations in every deployment, and the first one applies and reverses cleanly. No environment carries a hand-made column.

    Reversibility is the part that matters. A migration that cannot be undone is an outage waiting for a bad week.

SIMULATION LAYER 03 / 05

Where your data would live

A separate instance, with its own database.

Two reasons, both practical. Spreadsheet parsing is a spiky allocator with no upper bound on what an upload contains, so one unusual workbook must not be able to degrade anything else. And customer financials should not share a database whose ownership boundary is still being settled elsewhere.

India is the domicile and INR the primary currency, which is also the assumption the parser and the panel prefixes are built around.

Decision pending

The dedicated instance is not yet provisioned.

It is a real recurring cost and it has not been approved yet, so it is stated here as the intended posture rather than as something already in place.

If you are evaluating this as a design partner, ask us where it stands on the day you ask. The answer will be specific.

SIMULATION LAYER 04 / 05

Not yet proven

The list most security pages leave out.

A vendor who tells you only what passed has told you nothing about their judgement. These are open, dated and tracked internally, and they will be closed before anything is called production.

  • No completed restore drill

    We hold one dated restore-rehearsal record, and it documents a pre-flight that did not execute — availability check not run, target recovery time pending. It is a record of a failed attempt, not evidence of disaster recovery, and we will not present it as one. A real drill has to be run.

  • Identity provider untested against a live project

    The integration is complete and tested against locally-minted tokens in the provider's claim shape. That proves our half of the contract and cannot prove theirs. Two hand-checks close it once a real project exists.

  • No production data yet, therefore no scale evidence

    Parser behaviour on genuinely large or pathological workbooks is bounded by design intent, not by measurement, because we do not yet have the corpus. This is the main reason we are asking for real exports.

The repository also contains adversarial self-audits that contradict earlier marketing material. Where an audited figure and a marketing figure disagree, the audited one wins everywhere.

SIMULATION LAYER 05 / 05

Send an anonymised export first.

Values stripped, shape intact. It is enough for us to tell you what would compute, and it does not require you to trust us with anything real yet.