Engineering standards, with the evidence beside every rule.

Beside each rule we build and ship to sits the test, restore or design choice that enforces it, so you can check the claim before relying on it.

Nine written rules make up SolaryxDev's software engineering standards, each enforced by a test, a restore or the design itself. Every change ships with the test that proves it, and the full suite passes before any release. Releases start beside the live version. Money checks fail closed, and a check that cannot run counts as failed.

A check that cannot run is not a pass. It is red.

SolaryxDev release standard

Nine rules we can show working.

The last column names what enforces each rule: a release test, a real restore or the design itself.

Nine rules, what each means in practice, and how it is proved.
Rule	What it means in practice	How it is proved
New behaviour ships with the test that proves it	The test lands in the same change, and it has to fail on the unfixed code before anyone trusts it.	The full suite runs before every release.
An exit code is not evidence	Nor is a green tick, an HTTP 200 or a status page. The proof is the artefact that changed, or an attempt that failed when it should have.	Backups are proven by a real restore, with every recovered file opened.
Money guards fail closed	If a check that protects a charge cannot run, the system refuses and the charge waits for a person.	A duplicate-payment check that errors stops the write, and a release test proves it.
Shown equals booked equals charged	The figure on the client's screen, the entry in the ledger and the amount charged to the card are one number from one source.	Money arithmetic and double-billing tests run in the release suite.
Review equals sign	The contract a client reads on screen and the PDF they sign are identical to the byte, in every application that shows them.	Golden-render tests run on every release. After the release of 10 September 2026, the contract template carried the same file hash in both live applications.
Every record route authorises on its own	A route that returns a record checks this caller against this record every time, whatever menu the request came through.	Isolation tests in the release suite.
Access is stripped at the read	A role that may not see a figure is never sent it. Nothing is fetched first and hidden later.	The same rule decides what a knowledge assistant may retrieve.
One client, one boundary	Separate containers, databases and credentials per client, with no route between them.	A separate environment for every client.
No model moves money, deletes or makes first contact	Those actions run in deterministic code and wait for a person.	Set out on the model guardrails page.

Silence counts as a failure.

A check that could not run is logged as unreachable, and unreachable is red. Silence once let one of our own backups report green for weeks while it was missing the only file that could decrypt it.

Our tooling is built to that rule. The release gate sends every stray call to a closed local port and refuses to start if pointed at production, so a test run cannot touch the live books.

A backup passes only when its restored files and bytes match the archive's manifest and every recovered file opens to its completion marker. In monitoring, silence has to read red, or 'no news' and 'it died three weeks ago' look the same.

Clients stay apart at two levels.

At the infrastructure level, no two clients share a container, a database, credentials or a network path. Inside the application, every route that returns a record checks on every call that this caller may see it.

Our own client portal works the same way. Someone linked to several companies signs in once, and none of those companies can tell the others exist.

Five pages carry the detail.

The release gate sets out what every change must pass, and how a release is taken back.
Model guardrails lists what a model may never do alone, and the code that holds it there.
The stack and models radar places each model, tool and practice in a dated ring, from Use to Hold.
Security and data covers isolation, restore-tested backups and where your system is hosted.
Model evaluation and assurance explains the test sets every model change has to pass.

We publish the method in place of logos.

No client has yet agreed in writing to be named, so this site shows no logos. The method is what we can show, down to the figures from our last release.

Every client system is built to these rules, and so is the platform that runs our own accounting and client email. The route from the first call to the warranty is set out in our software development process.

Frequently asked questions

What engineering standards does SolaryxDev hold its software to?

What does 'new behaviour ships with its test' mean in practice?

Any change that adds or fixes behaviour carries its own automated test. That test runs against the unfixed code first, where it has to fail, and only then is it trusted. The full suite then runs before the release.

Who owns the code you write for us?

You do, once it is paid for. Section 06 of the agreement makes the source for paid work yours, and you may ask for it at any time.

What is a release gate?

The set of checks a change must pass before production. Ours runs the full automated suite, compares rendered client documents with their approved versions, and deploys beside the live version so one command can undo the release.

What does fail closed mean?

When a check that protects money cannot run, the system stops. A duplicate-payment check that errors blocks the charge, and the payment waits for a person to enter it by hand.