Furth FortuneM9 reference

M9 reference library

M9 system reference.

M9 connects its runtime, language, data systems, renderer, tools, and control layers. Each page shows a system diagram and a concrete example.

For technical teams and program management

Use these pages to understand system boundaries, data flow, operating behavior, and questions for a pilot. They are not build instructions or certification claims.

Start with the task

Choose a short path into M9

Each path begins with a program question and links three maps in reading order.

System diagram

One application contract across the M9 fabric

Mission behavior stays visible at the center. Shared foundations surround it, and every host reaches the same types, data, and operating evidence.

Application contract .tri source + configuration
Trident behavior • types • tasks
Data MerDB • MerBuf • MerFS
Render + assets Thalassa • Nautilus
Compute + host Keel • Fathom • BenthOS
Deployment edge
WatchTabletDesktopHeadsetService

Integrated platform

Start with the whole system

M9

One runtime, one data model, and one debug path

M9 is a software platform for applications that must run on different devices and keep the same rules and data. Trident defines behavior. Shared services handle data, rendering, assets, compute, and deployment.

Read overview

System diagram

Foundations meet at one application contract

Trident holds application behavior. The other foundations provide shared data, rendering, compute, asset, storage, host, and device mechanisms.

Application contract .tri + configuration
BehaviorTridentrules • workflow • policy
DataMerDB • MerBuf • MerFSrecords • bytes • objects
VisualNautilus • Thalassaassets • scenes • device output
ComputeKeelmath • simulation • ML
HostFathom • BenthOSservices • devices • hardware

Mission foundations

Core capabilities that work together

Each foundation has a clear job. Together they connect mission logic, data, devices, assets, compute, and operations.

Trident

One program in text and node views

Trident is a typed language for application rules and workflow. Its script view and node view edit the same program graph. The language includes bounded loops, complete branches, tasks, errors, and distributed locks.

Read overview Thalassa

One scene scaled from a watch to a headset

Thalassa renders one declared scene on devices with different screen, memory, and graphics limits. Each backend reads the same render program and is checked against a software reference image.

Read overview MerDB

Typed data with declared access paths

MerDB stores typed records and requires applications to declare how they will read them. It rejects broad, unplanned scans and exposes ordered change streams for other services.

Read overview Fathom

The host boundary from edge node to service

Fathom connects MerTek applications to files, networks, processes, and deployed nodes through a small host interface. Transport, trust, and rollout choices are declared policy.

Read overview Keel

Shared math, simulation, and ML kernels

Keel supplies fast, reusable compute functions. The functions take parameters from Trident; they do not contain mission thresholds or policy.

Read overview Nautilus

One import boundary for outside assets

Nautilus decodes source formats such as GLB, PNG, JPEG, and FBX into MerTek mesh, texture, rig, animation, and point-data profiles. Render code reads only those profiles.

Read overview MerBuf

Typed bytes with schema identity

MerBuf encodes declared values into compact bytes. The payload carries enough type and schema identity for a receiver to check it before use.

Read overview MerFS

One byte-store contract across storage systems

MerFS stores and retrieves opaque bytes by stable key. Local disk, remote object storage, and memory-backed storage implement the same narrow contract.

Read overview BenthOS

A small base for controlled devices

BenthOS provides the low-level mechanisms needed by a MerTek node: startup, memory, scheduling, device access, and host boundaries. Applications still remain Trident plus configuration.

Read overview

System diagram

Three products work on the same application state

The product layer uses the same M9 runtime and application model. It does not create a second platform path.

AuthorStudio Kit

node view • script view

validated source
ControlMerTekStak

evidence • generations

approved rollout
AccessMerTek.io

identity • grants

approved session
M9 application stateone source generation • one runtime • one data contract

Platform products

Ways teams use and govern the platform

MerTekStak

The control plane for applications and releases

MerTekStak stores application definitions, release state, test evidence, and rollout decisions. It runs as a MerTek application and follows the same rules as the software it manages.

Read overview MerTek.io

Identity and capability routing for applications

MerTek.io signs in a user, resolves allowed applications, and routes the user to them. Each application remains responsible for its own data and action permissions.

Read overview Studio Kit

Tools for building Trident applications

Studio Kit combines node editing, script editing, reusable libraries, data views, and validation. It edits the same application source that runs in production.

Read overview

System diagram

Assurance fabrics cross every operating layer

Type, boundary, security, test, release, deployment, and debug rules apply across the full stack.

Operating layer
Definetypes + boundaries
Controlidentity + tenancy
Provegates + release
Operatedeployment + debug
Source + configuration
Application generation
Shared runtime
Fielded node

Assurance fabrics

Controls that cross every system

These shared practices make security, evidence, data life, support, and change visible across the platform.

Evidence and Verification

Checks with explicit scope and verdicts

The gate system records what each check covers, what it ran, and whether it passed, failed, or was held. Aggregate profiles list the checks they include.

Read overview Release Assurance

A repeatable path from source to release

Release assurance resolves dependencies, builds artifacts, records their contents, and refreshes derived inventories from the approved source tree.

Read overview Persistence

From typed value to durable storage

The persistence path encodes typed rows, stores large objects by key, records pending writes, and exposes ordered committed changes.

Read overview MerTekTypes

One type registry for language, storage, and exchange

MerTekTypes defines the names and shapes used by Trident, MerDB, MerBuf, and tools. Logical types stay separate from their wire and storage forms.

Read overview Operational Debug Views

One debug model for scenes and services

Systems publish typed state, events, timing, and boundaries. Rendered applications show overlays; background services show the same facts in service views.

Read overview Controlled Deployment

Separate paths for application and platform updates

Trident and configuration updates use a live application path. Compiled runtime and device changes use a staged node rollout. Both paths retain state and rollback information.

Read overview System Boundaries

Layer rules that show where code belongs

Names and dependency rules separate core mechanisms, Trident policy, applications, products, and device hosts. A lower layer cannot depend on mission-specific behavior.

Read overview Security and Tenancy

Deny-by-default checks at each boundary

Identity, application, data, service, tenant, and device checks each require a declared grant. Passing one check does not bypass the next check.

Read overview Coordinated Delivery

Isolated work with named ownership and proof

Each change has an owner, an isolated work area, required checks, and a verified merge to the shared main line. The same process applies to human and assisted work.

Read overview

Pilot scope

Start with one measured problem.

Define the input data, target devices, required behavior, failure cases, and evidence before the pilot starts.

Request a technical briefing