Skip to content
Creation1618
The suite

Five lines. One record that survives being questioned.

Each runs standalone — its own login, its own data perimeter, its own agreement.

Register once and every demo below unlocks for fourteen days.Register for demo access

AssetDNA

Pilot-ready

The verifiable operating record of a building.

How it runs

Technology profile

Architecture
Cloud-hosted, API-first web application over a PostgreSQL system of record, with scheduled server-side jobs.
The record
An append-only, hash-chained operating record — tamper-evident, and exportable in full at any time.
Verification
Externally timestamped to RFC 3161, so a counterparty re-derives the record offline, without us, using standard tooling.
Intelligence
Deterministic, not learned: rule-routed answers computed server-side and shipped with their citation, plus a projection whose uncertainty band is earned by backtesting the method on the record’s own history.
Integration
Read-only one-way connectors, a published inbound contract and export schema (JSON Schema 2020-12), an OAuth 2.0 accounting link, a key-authenticated read API and open-data feeds.
Security
Per-tenant isolation with role-based access, encrypted in transit and at rest, scoped revocable credentials and time-boxed share links, with an access and verification audit trail.

Public standards implemented

  • RFC 3161
  • JSON Schema 2020-12
  • OAuth 2.0
  • SHA-256
  • SDMX-CSV 2.1
  • ISO 4217

Implemented against the published specifications. No conformance certification is held or claimed.

Every figure is computed from the verified record and shipped with its citation. The forecast refuses to answer when the history behind it is too thin — a property we consider a feature.

Sectors
Property & built environment · Finance & investment · Environmental technology

TXRA

Working build

Who held what, and when — provable on demand.

How it runs

Technology profile

Architecture
Multi-tenant cloud platform: managed PostgreSQL as the system of record, serverless edge functions for privileged operations, one typed codebase serving web, iOS and Android.
The record
An append-only, hash-chained event ledger plus a separate append-only administrative audit trail that cannot be updated or deleted — including by an administrator.
Verification
Record integrity can be recomputed from an export by an outside party, and verification runs inside the product today. No external timestamping authority is wired, so integrity is checked against the record TXRA itself keeps.
Intelligence
The analytical core is deterministic, not learned: feasibility, triage and risk scoring are weighted rule engines that return every category’s contribution. A language model drafts and extracts; it never decides.
Integration
Bank-feed capture is built against Australia’s Consumer Data Right and consumed through a third-party accredited data recipient — TXRA holds no accreditation of its own, and the connector is not live. Full self-service export under Australian Privacy Principle 12.
Security
Row-level isolation policies applied across the data model, role-and-permission access control, per-tenant scoping on every deal surface, encryption in transit and at rest, self-service export and account deletion.

Public standards implemented

  • SHA-256
  • Australian Privacy Principle 12

Implemented against the published specifications. No conformance certification is held or claimed.

Every score decomposes into the weighted inputs that produced it, and a human can override any component on the record. A language model drafts and extracts; it never decides, and the product runs rules-only without it.

Sectors
Finance · Property & infrastructure · AI & digital

AllotX + BPN

Pilot-ready

Promotions and rewards a participant can check for themselves.

How it runs

Technology profile

Architecture
Multi-tenant, API-first cloud platform; separate member, operator and administrator zones over one core, with per-tenant isolation enforced in the database itself.
The record
Every balance — points, prizes, collectibles and cash — sits on a purpose-built double-entry ledger with two-phase escrow transfers and ledger-enforced non-negative accounts.
Verification
Every promotion publishes proofs an outsider can re-run to confirm the recorded outcome, with no account. The audit chain’s head is timestamped by an independent RFC 3161 authority where one is configured — and the public page reads “pending” rather than claiming a timestamp that has not been issued.
Intelligence
A rules-based decision engine, not a learned one: it reads a brand’s own trading data, surfaces where revenue is leaking, ranks the opportunities by size, and can launch the matching campaign inside budget, discount and authority limits.
Integration
Inbound event API with per-tenant keys, signed-token QR, HMAC-SHA-256-signed outbound webhooks, an embeddable white-label widget, W3C Web Push, and an unauthenticated public read API for verification.
Security
OAuth 2.0 single sign-on, role-based operator and administrator access, row-level tenant isolation, AES-256-GCM on stored integration secrets, append-only audit records, data exportable on demand.

Public standards implemented

  • RFC 3161
  • OAuth 2.0
  • JWS HS256
  • W3C Web Push (RFC 8291/8292)
  • HMAC-SHA-256
  • AES-256-GCM

Implemented against the published specifications. No conformance certification is held or claimed.

Decision automation with operator-set guardrails — inspectable and auditable today, built behind an interface designed to take a learned model later. We do not claim a trained model.

Sectors
Retail & hospitality · Financial services · Digital platforms & AI · Food & beverage

TraceX + CrestX

Working build

Custody and evidence, from the factory floor to the invoice.

How it runs

Technology profile

Architecture
Two multi-tenant applications on a relational store. TraceX is event-sourced and embeddable — widgets, a JavaScript SDK and a REST API; CrestX is server-rendered with a closed perimeter.
The record
TraceX keeps an append-only event log as the source of truth with every view derived from it. CrestX keeps a per-tenant hash-chained activity ledger plus a content fingerprint on each evidence item.
Verification
CrestX re-verifies its own chain and fingerprints on screen. TraceX serves an unauthenticated per-unit provenance page addressed by GS1 Digital Link. Neither carries external timestamping, and neither claims it.
Intelligence
Deterministic and explainable, not learned: TraceX scores a match into a confidence figure that prints its own reasons; CrestX scores evidence into a transparent provenance readout capped by its strongest tier.
Integration
Open-format exports, route-served: GS1 EPCIS 2.0 traceability documents in JSON-LD, Peppol BIS Billing 3.0 / UBL 2.1 invoice XML, and GS1 Digital Link identifiers. One OAuth 2.0 accounting connector is built and awaiting credentials; reconciliation runs against the platform’s own records, not a live bank feed.
Security
Per-tenant isolation enforced at a single choke point in every query, role-scoped party portals, read-only reviewer rooms, scrypt password hashing, API keys stored only as hashes, signed expiring embed tokens, AES-256-GCM on stored credentials.

Public standards implemented

  • GS1 EPCIS 2.0
  • GS1 Digital Link
  • JSON-LD
  • Peppol BIS Billing 3.0
  • OASIS UBL 2.1
  • OAuth 2.0
  • SHA-256
  • AES-256-GCM

Implemented against the published specifications. No conformance certification is held or claimed.

Both products score their records — settlement confidence in TraceX, evidence strength in CrestX — with deterministic logic that shows its working, rather than a black-box model.

Sectors
Smart logistics & supply chain · Agritech & food · Advanced manufacturing · Finance

EarthX

Early build

Everyday actions, turned into assurance-ready evidence.

How it runs

Technology profile

Architecture
One cross-platform codebase across iOS, Android and web over a multi-tenant PostgreSQL design.
The record
An append-only, hash-chained evidence chain over graded emissions records and the reductions and retirements applied against them.
Verification
An outsider re-derives the whole chain offline from a published pack format — a JSON Schema and a one-page algorithm. No external timestamping is wired, and none is claimed.
Intelligence
Deterministic, not learned: weighted provenance rules with a hard ceiling that blocks the top confidence band unless something independent attests the record, over published emission-factor arithmetic.
Integration
Manual, spreadsheet and connector capture in; an open self-verifying pack and spreadsheet-friendly export out. Bank-feed capture is written but credential-gated and inactive.
Security
Per-tenant row-level isolation across owner, admin, member and auditor roles, with a database guard that rejects any update or delete against the event chain.

Public standards implemented

  • JSON Schema 2020-12
  • SHA-256
  • HMAC-SHA-256
  • GHG Protocol Scope 1/2/3

Implemented against the published specifications. No conformance certification is held or claimed.

The evidence engine is deliberately deterministic — every score and every figure is a rule an assurer can re-run and reproduce exactly, with no model in the loop. Language models appear only in optional back-office assistants that draft copy for a human to approve, never to grade evidence.

Sectors
Environmental technology · Finance · AI & digital

The technology

Built so the other side can check it

Two decisions we will defend in the room. Everything shown is in the build today; where a capability is dormant until configured, it says so.

Timestamps from someone who is not us

No node to run, no token to hold, no chain governance to trust. Where a platform does not have this, its profile above says so.

AI where it cannot fabricate

A lender, an assurer or a regulator has to be able to re-run the arithmetic. A black box cannot be re-run — so it is the wrong tool for the load-bearing part.

Why we give the interface away

The defensible asset is the accumulated record, not the file format.

Publish the interface

Export schemas, open document formats and public verification endpoints — free, versioned, ours to maintain.

Partners build against it

A counterparty or vendor integrates without buying anything or signing anything.

They run on the engine

The verification, settlement and scoring machinery behind the interface is the part we keep.

The record compounds

Every verified day deepens an operating history that cannot be backdated.

01

Verification is dormant, never faked

The same code path drives a real timestamping authority the moment you point it at one, and labels itself a demonstration stub when you have not. Each historical anchor is re-verified by the authority that issued it — so switching a provider on cannot retroactively invalidate what came before.

02

The language model is a router, never a synthesiser

Structured output constrains it at the API layer to a whitelisted intent or a refusal, its answer is re-validated server-side, and any failure falls back to deterministic code. The worst it can do is pick the wrong permitted question — it cannot fabricate a figure.

03

Forecast uncertainty is earned, not asserted

Bands come from replaying the identical method over the record’s own history and scoring it against what actually happened, with a hard refusal gate in code when the history is too thin. The system declines to forecast rather than produce confident-looking nonsense.

04

Privacy floors live in code, not in a policy

A cross-customer benchmark cannot emit a figure until the cohort behind it is large enough. That is a condition the aggregation enforces before it computes, not a promise in a document.

05

Composable without a shared build

Products on irreconcilable renderers — native mobile and server-rendered web — still compose at runtime through scoped keys and signed embed tokens rather than a shared build. Each stays independently deployable, and separately licensable.

06

Audit trails an administrator cannot edit

On several platforms the append-only guarantee is enforced by the database itself, which rejects an update or delete against the event chain — including one issued by an administrator, including one issued by us.

How it is built — the delivery stack
  • TypeScript end to end — one language across web, mobile and serverless, with shared typed contracts
  • React 19 throughout; server-rendered web on Next.js with the App Router and Server Components
  • Cross-platform mobile from a single codebase via React Native and Expo
  • PostgreSQL as the system of record, schema-first with migrations in version control
  • A dedicated high-throughput double-entry ledger engine alongside the relational store, for financial-grade balance integrity
  • Serverless edge functions for background, integration and agent work
  • Scheduled jobs for periodic verification, anchoring and index recomputation
  • API-first: a versioned REST read API and embeddable widgets on every product
  • Automated unit and integration suites across the estate, with browser end-to-end coverage on the larger products

Categories, not construction. The deep-dive happens under a mutual NDA.

What the stages mean

Pilot-ready
Built end to end and exercised against real external checks. Ready for a first pilot on your own data.
Working build
The full product runs end to end today on a seeded demonstration dataset. Production connectors and live tenancies are next.
Early build
A working prototype covering the core loop. Parts of the product are designed and not yet built; we say which.

Sectors we build for

  • Smart logistics & supply chain
  • Agritech & food technology
  • Advanced manufacturing
  • Environmental technology
  • Property & built environment
  • Finance & investment
  • Health & life sciences
  • Retail, hospitality & consumer
  • Research commercialisation
  • AI & digital
Platforms · Creation1618