40+ clients in production4,200+ deterministic engines477 tables · one control planeSealed lift plans · QC + ONBuilt in Canada · bilingual15 companies on CRANEbee®40+ clients in production4,200+ deterministic engines477 tables · one control planeSealed lift plans · QC + ONBuilt in Canada · bilingual15 companies on CRANEbee®
MAXORTechnologies Inc.Maxor Technologies Inc.
ArchitectureProjectsHow We WorkStandardAboutContact
ArchitectureTalk to us
MAXORTechnologies Inc.Maxor Technologies Inc.

Canadian engineering and technology firm — lift plans we engineer, software we ship, partners we distribute.

Anchored
Québec, Canada
Delivered
English + Français
Legal entity
Maxor Technologies Inc.

What we do

  • Lift planning
  • Emergency lift plans
  • CRANEbee® software
  • Murlink® solutions

Solutions

  • Product suite
  • Consulting
  • Implementation
  • Custom software
  • Canadian sovereignty

Products

  • Heisen
  • MaxorConnect
  • Hullsmith Horizon
  • Hullsmith Firewall
  • TensorYard
  • slopGrade
  • Maxor Sentinel

Industries

  • Oil & Gas
  • Petrochemical
  • Mining
  • Nuclear
  • Renewable Energy
  • Ports & Marine
  • Shipbuilding
  • Civil Infrastructure
  • Steel & Metals
  • Manufacturing 4.0
  • Engineering & EPC
  • Specialized Transport

Company

  • About Maxor
  • Architecture
  • How we work
  • Project references
  • Contact
SubstrateHeisen — deterministic computingby Maxor Global LLC

© 2026 Maxor Technologies Inc. All rights reserved.

Privacy policyCookie policyTerms of useLegal noticeAccessibilityPhoto credits
tensoryard · receipton
⊞ compute · chain-ladder reserve · epoch 2026
✓ canonical encode ✓ merkle root ✓ signed
▲ auditor replay · input digest mismatch
✕ REJECT · recomputation ≠ receipt
✓ re-run · digest identical · Ed25519 ok
Products/TensorYard
🟡 FoundationCloud · Self-hosted · Air-gap

TensorYard

A regulated number your auditor can replay — bit-for-bit, offline, trusting nothing.

TensorYard is the deterministic-compute authority for regulated domains. A regulated computation is run by a pure arithmetic engine — never a language model — sealed in a signed receipt, and an independent auditor re-runs it offline to get an identical digest. Same input, same output, or the receipt is mechanically rejected. Model risk, proof-of-reserves, insurance reserving: the number the person who signs — and carries the liability — can defend, years later, without us.

Availability — Early Access

TensorYard is not a self-serve product. It runs today at v0.1 — the compute → signed receipt → offline verify core is real and running — as a regulated design-partner engagement. You get it by conversation, sold to the signatory who carries the liability, never as a line on a quote. This page documents it because the person who signs has a right to know exactly how the number is proven.

Ask a technical question See the full suite

Ed25519

Every receipt cryptographically signed

Bit-for-bit

Replayed by your auditor, offline

0

Language models in the compute path

WORM

Hash-chained, append-only evidence ledger

What it is

An authority, not a spreadsheet.

A regulated number is only as good as your ability to reproduce it under challenge. TensorYard runs the computation on a pure arithmetic engine — deterministic by construction, no probability, no model — and emits a signed receipt that binds the inputs, the engine version, and the result into one tamper-evident record. An auditor takes that receipt to their own machine, off your network, and recomputes: an identical digest, or a mechanical rejection. There is no 'trust our platform' step, because there is nothing to trust — only arithmetic anyone can rerun.

How it works

Compute. Seal. Replay.

One regulated computation, three moves — and the last one belongs to your auditor, not to us.

01 — Compute

A pure arithmetic engine runs the regulated calculation — reserve derivation, standardized credit RWA, chain-ladder — pinned to a fixed runtime epoch. Same inputs always produce the same output, on any machine, any year.

02 — Seal

The result is canonically encoded, hashed into an RFC-6962 Merkle tree, Ed25519-signed, and appended to a hash-chained WORM ledger. The receipt binds inputs, engine version, and figure into one tamper-evident bundle.

03 — Replay

Your auditor takes the receipt to their own iron — offline, air-gapped if they wish — and recomputes. An identical digest verifies the number ; any drift is a mechanical REJECT. No access to us required, ever.

The receipt

What a signed receipt actually binds.

The receipt is the product. It is not a log of what happened — it is a self-contained proof a third party can verify with no trust in us and no connection to our systems.

01

The inputs, canonically

Every input is canonically encoded, so the same data always hashes to the same value — no ambiguity of formatting, ordering, or precision to argue about later.

02

The engine epoch

The exact engine version is pinned to a runtime epoch and bound into the receipt. A computation from 2026 replays under 2026's engine, not whatever ships next year.

03

The Ed25519 signature

An Ed25519 signature over the Merkle root makes the receipt tamper-evident : change one input, one digit, one byte, and verification fails — cleanly, mechanically, offline.

What it does

Deterministic, sealed, sovereign.

Built so the number survives an audit years later — on the auditor's terms, not yours.

Pure engines, not models

Regulated figures are computed by pure arithmetic engines — deterministic by construction. No probability distribution, no model to retrain, nothing to drift between the run and the review.

Signed, replayable receipts

Every computation emits a self-contained receipt — canonical inputs, engine epoch, Ed25519 signature — that reproduces bit-for-bit on any machine, with no connection back to us.

WORM evidence ledger

Receipts are appended to a hash-chained, write-once ledger. The order is provable and the history cannot be silently rewritten — the audit trail is the ledger itself.

Offline, air-gap verify

Verification needs no network and no vendor. An auditor recomputes on their own hardware, fully disconnected — because the proof is arithmetic, not a service call.

Mechanical rejection

There is no 'looks close enough'. A receipt whose recomputation does not match is REJECTED — a binary, defensible verdict, not a human judgment call.

Your keys, your perimeter

Run the engines and hold the signing keys inside your own environment. The regulated data — and the authority to sign the number — never leave your control.

What it rejects

The ways a regulated number goes wrong.

Each of these is how an audited figure quietly stops being defensible. TensorYard turns every one into a mechanical failure a reviewer can point to.

Non-reproducible results

A figure nobody can recompute — the number in the report that no longer matches when you re-run the model. Rejected: the receipt either replays or it does not.

Silent tampering

An input, a parameter, or a result quietly edited after the fact. The Ed25519 signature over the Merkle root fails the instant a single byte moves.

Engine drift

This year's engine giving a different answer to last year's computation. The pinned runtime epoch makes the original run replay under its own engine, not the current one.

Rewritten history

A record slipped into — or out of — the audit trail. The hash-chained WORM ledger makes the order provable and any rewrite detectable.

Model opacity

A figure defended only by 'the model said so'. TensorYard's engines are pure arithmetic — the reviewer reruns the math, they do not take it on faith.

Vendor lock-in of proof

Evidence you can only verify by logging into the vendor. The receipt verifies offline, on the auditor's own iron — the proof outlives the relationship.

Where it runs

Hosted, or entirely inside your perimeter.

Start hosted for a pilot ; bring the engines and the signing keys in-house when the regulator — or your data-residency rule — demands it.

Cloud

Fully managed for a design-partner pilot — the fastest way to put a signed receipt behind a regulated computation, nothing to provision.

Self-hosted

Run the engines and hold the signing keys inside your own environment. Your infrastructure, your control plane — the regulated data never leaves your network.

Air-gapped

Fully disconnected for the most sensitive reserving and risk work. Compute and verify where the data lives, because the proof does not need the internet.

Who it's for

The person who signs — and bears the liability.

The signatory whose name is on the regulatory opinion, and the teams who hand them a number that has to survive a challenge.

Appointed actuaries & signing officersModel-risk teams (SR 11-7)Crypto custody & proof-of-reservesInsurance reserving & reinsuranceRegulated quant & risk functionsSovereign & air-gapped deployments
Part of the suite

One deterministic philosophy, across the suite.

TensorYard shares the Maxor posture : deterministic math over black-box models, verifiable over trust-us, sovereign-deployable by default. It is the compute authority that sits beside Heisen and the grounding fabric in the evidence substrate behind every Maxor surface.

Explore the Maxor suite
At a glance

Availability

Early Access

Status

🟡 Foundation

Deployment

Cloud · Self-hosted · Air-gap

Owner

Maxor Global LLC

[Availability]

You don't buy TensorYard. You partner on it.

TensorYard runs today at v0.1 as a regulated design-partner engagement — the compute, the receipt, the offline verify are real. If you sign a regulated number and want it to survive a challenge years from now, ask : we will walk you through exactly how the proof is built and replayed. That conversation is a technical one, and we will keep it that way.

Ask a technical question See what we sell
TensorYard — FAQ

TensorYard, answered

TensorYard is a deterministic-compute authority for regulated numbers. A regulated computation is run by a pure arithmetic engine — never an LLM — and sealed in a signed receipt, so the number can be defended long after it was produced.

An independent auditor re-runs the same computation offline. If the recomputation produces an identical digest, the result is accepted; if it differs in any way, it is mechanically rejected. Verification does not depend on trusting Maxor — it depends on the math reproducing exactly.

Language models are non-deterministic: the same prompt can yield different outputs, and a result cannot be re-derived to an identical digest. Regulated numbers need pure, reproducible arithmetic that an auditor can recompute independently — which is exactly what TensorYard's engines provide.

TensorYard is at Foundation status (v0.1). The compute → signed-receipt → offline-verify core is real and running, and its registry ships a focused set of regulated engines. It is offered as a pilot design-partner engagement — not a self-serve product — and there is no paying customer yet.

It is for regulated environments where a number must be auditable and defensible — the value has to hold up to independent recomputation. It is sold to the signatory who carries the liability for that number, through Maxor's software and advisory engagement.