Technology

Scalata Code

Underneath the answers that arrive as workbooks, the documents that rebuild themselves and the apps that appear from a sentence, there is one thing happening: code is being written and run against your data.

Not suggested — written, checked, executed, and repaired when it fails. The model proposes a plan you can read, generates against it, runs its own checks, and patches the line that broke rather than starting the file again. Only then do the results come back to you.

And it runs somewhere you can point at: a sandbox belonging to your organisation alone, with a ceiling on what it may use and nowhere to send anything it was not given. That is what makes it safe to aim at the real ledger rather than at a copy of it.

It agrees the plan first

Before a line is written it produces a specification — the inputs, the calculations, the shape of the output. When the work touches your tables, that plan is put in front of you to approve, change or reject.

It checks its own work

Syntax, brackets, imports and completeness, and then the harder question: does this code do what the plan said it would? A model reads the two against each other before anything is allowed to run.

It patches, it does not rewrite

A failure produces a surgical change to the lines at fault, keeping everything that was already right. Three attempts; if it is still wrong after that, it starts again with the error in hand rather than looping.

You get the files, not the transcript

Whatever the run produced is picked up as it ends — a workbook, a chart, a document, a running application — and handed to you with the code that made it.

Languages

Eleven stacks, one loop

Python does most of the work, because most of the work is data. But the language is chosen for the job rather than for the platform, and the same plan-check-run loop wraps every one of them.

Each stack is a pre-built environment rather than an empty machine — the libraries are already installed, the scaffold already exists, and the agent reads a guide to that stack before it writes anything. Which is why the first run is a run, not a twenty-minute setup.

PythonAnalysis, modelling, everything with a dataframe in itWeb appReact and TypeScript, served liveWeb app + APIThe same, with a Python backend behind itJavaLong-lived business logicGoFast, small, self-containedRustWhere correctness and speed both matterC++Numerics and anything close to the metalRStatistics, in the language statisticians useScalaData work that belongs beside SparkRubyScripting and quick transformationsCOBOLBecause some of your systems still speak it

The sandbox

Somewhere it cannot do any harm

Generated code is only useful if it can be pointed at the real thing, and only safe if the place it runs is genuinely walled off. Every session gets its own machine inside your organisation's own space, and it is taken back the moment nobody is using it.

One machine per sessionNothing you run shares a process with anything elseYour own namespaceSessions are walled into your organisation, not a shared poolA ceiling on everythingMemory, CPU and time are capped before anything startsNowhere to phoneOutbound network is closed except to what it was grantedSized from last timeEach run is given what the last one actually usedReclaimed when idleA sandbox nobody is watching is taken back

Your data

It reads the shape before it reads the rows

Given a table, it asks for the schema first — columns, types, sheets — and only pulls sample rows when the schema is not enough to write against. A spreadsheet is not loaded into a prompt; it is opened by code, in the sandbox, with the file mounted beside it.

The same is true of everything else it reaches. Warehouses, buckets, drives and APIs are resolved through the connections you have already made and the grants you already hold, so what the code can open is exactly what you can open — and the figures in the answer came from running the file rather than from guessing at it.

How connections workWhat gets built with it
Schema first

Columns before contents

Types, sheets and headers are read before any rows are, so a wide file costs a glance rather than a download.

Files mounted

Opened, not pasted

Attachments sit in the sandbox's own folder and are read by the code, which is why a hundred-megabyte extract is not a problem.

Your grants

Nothing new is opened

It reaches sources through connections you already hold — the code inherits your access rather than being given its own.

What comes out

Files, not a transcript

When a run finishes, whatever it created is picked up and handed to you — workbooks, CSVs, charts, documents. If what it built was an application, it is served live and becomes a widget in your organisation.

Nothing is locked in. The code can be downloaded in full, an app's database exported, and every execution is kept with the person who ran it — so a figure produced in March can still be traced to the lines that produced it.

Artefacts

Excel, CSV, charts, documents

Detected as the run ends, kept with the session, and offered as downloads.

Applications

Served live, then pinned

A web app is started behind a signed preview and becomes a widget your team can open — with alerts, a schedule and a database of its own.

The record

Kept, with who ran it

Every execution is stored with its files and its owner, and screened by the same guardrails as every other surface.

Turn weeks of expert work into minutes

See how Scalata fits your team, your data, and your controls.

Contact Sales