Build an application
How do we turn a workflow into deployed software?
Platform and language reference
Technical reference.
Read about the Alba web platform, the MTK systems platform, and the Trident application language. The system maps below cover MTK components and their boundaries.
Platforms, language, and system maps
Start with a platform overview or the language reference. Use the diagrams to follow data, control flow, and host boundaries.
Start here
Alba and MerTek
Alba is the web platform in use today. MerTek is future technology with a release in 2027, bringing together Trident, Cutlass and shared systems for data, graphics and devices. The year groups in the navigation organize the MerTek technology roadmap. Every page starts with a worked example; hover any dotted word for its definition.
Current / Stable
Alba
Alba is the current web application platform. Its C# services, generated interfaces, database, and deployment tools support existing applications.
Read reference 2027MerTek
Future technology for a 2027 release: Trident, Cutlass and shared systems for data, graphics and devices.
Read referenceStart with the task
Choose a short path into MTK
Each path begins with a program question and links three maps in reading order.
Move and store data
How does a typed value cross a process or survive a restart?
Prove and support a release
How do we test, field, and diagnose one change?
System diagram
One application contract across the MTK fabric
Application behavior sits at the center. The shared systems surround it, and every device runs the same types, data and rules.
Application contract
.tri source + configuration
Trident
behavior • types • tasks
Data
MerDB • Rune
Render + assets
Thalassa • Nautilus
Compute + host
Keel • Fathom
Deployment edge
WatchTabletDesktopHeadsetService
Integrated platform
Start with the whole system
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
Core systems
Core capabilities that work together
Each foundation has a clear job. Together they connect application logic, data, devices, assets, compute, and operations.
Trident
Application rules with units, bounds and named failures
Trident is the language MTK applications are written in. Every value states its type, every loop its pass count and every enum branch its members, and the compiler checks all three. A program reaches files, the network and devices only through the grant its host builds at launch.
Read overview ThalassaOne scene, from a watch face to a headset
Thalassa is MTK's renderer and scene engine, written in C. A Trident program declares one scene, and Thalassa draws it within each device's screen, memory and graphics limits. Every graphics backend is checked against the same software reference image.
Read overview MerDBTyped records, read only along declared paths
MerDB is the database engine behind MTK applications. It stores typed records in troves, and a program reads them by key, through an index the trove file declares, or from an ordered change feed. Every write to a record passes one commit point, and the store checks the declared schema when a program launches.
Read overview FathomThe host boundary, from crew laptop to fleet
Fathom is the host side of MTK: the tri process that runs Trident runtimes and joins them into one deployment. The host opens files, starts programs and talks to network peers; a Trident program only names what it was lent. Network input is checked for size, sender and shape before any handler sees it.
Shared math kernels, with every decision kept in Trident
Keel is MTK's C library of math, geometry, simulation and machine-learning kernels. Trident programs reach it through typed calls such as t.collide, t.geo.carto, t.math and t.ml. A Keel kernel computes over the values it is handed and holds no thresholds, scenario values or decisions.
Supplier files stop at one import boundary
Nautilus is MTK's asset import boundary. It decodes supplier files such as GLB, FBX, PNG and JPEG once, into MerTek-owned mesh, texture, rig, animation, point and image profiles. Renderers and programs read only those profiles, by name and within a byte budget.
Read overview RuneTyped bytes that name their own shape
Rune is the binary format every MTK value takes in memory, in MerDB and on the wire. Each document carries its field names and complete types beside its values, in one canonical byte spelling. A receiver can check exactly what it holds before it reads a field, and a Trident program holds a Rune document as a chest value.
The device filesystem with no ambient root
MerFS is the filesystem a BenthOS device runs, its own engine apart from the MerDB storage that hosted deployments use. An application reaches files only through the granted scope the device handed it. A new file version takes its name only after its complete body and metadata pass their checks.
Read overview BenthOSThe device operating system, written in Cutlass
BenthOS is the operating system MTK runs on devices it controls end to end, such as pump-station gateways, kiosks and survey drones. It boots directly on the hardware, verifies each startup stage before the next one runs, and checks a capability before any device action. Applications stay Trident plus configuration: device changes reach them as typed events, and files reach them as scoped MerFS capabilities.
Read overviewSystem diagram
Three products work on the same application state
The product layer uses the same MTK runtime and application model. It does not create a second platform path.
node view • script view
validated sourceevidence • generations
approved rolloutidentity • grants
approved sessionMTK application stateone source generation • one runtime • one data contract
Platform products
Ways teams use and govern the platform
MerTekStak
The control plane, built as an MTK application
MerTekStak is the control plane that provisions hosted runtimes and decides which generation of an application runs. It is itself an MTK application: configuration plus Trident on the shared runtime, with its own store. Every write names the application, tenant and generation it expects, and every release keeps a digest chain from source to shipped bytes.
Read overview MerTek.ioRelease portal and front door for developer services
MerTek.io is the MTK application at mertek.io where teams find releases, read manuals and examples, download builds and keep their developer records. One account signs a person in and routes them to the applications and hosted services their team may reach. Each application still decides what that person may read or change.
Read overview WheelhouseEdit, run, and inspect an application in one workspace
Wheelhouse is the MTK workspace: edit source, read diagnostics, run tests, inspect a running program's state and preview assets in one window. Its page lets you try each panel on sample data.
Read overviewSystem diagram
Shared engineering controls 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
Deployed node
Shared engineering controls
Controls that cross every system
These shared practices make security, evidence, data life, support, and change visible across the platform.
Evidence and Verification
Every gate states its scope and leaves a verdict
The gate system is how MTK tests a change and gates a release. One planner turns a request into an ordered plan of gate leaves. Each leaf runs a declared command, keeps its evidence, and ends in pass, fail or hold.
Read overview Release AssuranceApproved source in, a traceable release out
Release assurance turns one source commit into release bytes anyone can trace back. One flag table fixes every build choice, and one compiler launcher feeds a content cache. Derived inventories are rebuilt from the final source, and the release record ties each executable's hash to its commit, gates, components and proof host.
Read overview PersistenceFrom a typed value to bytes that survive
Persistence in MTK is one path from a typed Trident value to bytes that survive a crash. The value is encoded once as Rune, stored by MerDB with any large body kept apart by key, and written to checked media through MerDurable. Each write reports what it survived, and committed changes leave in order through the change feed.
Read overview MerTekTypesOne type registry for code, storage and the wire
MerTekTypes is the one table of value types that Trident, MerDB, Rune and the tools all read. A type such as duration, guid or f64<family=length> means the same thing in a program, a database column and an encoded message. Each type's meaning is kept apart from the bytes that store and carry it.
See inside a running program without touching it
A running tri program publishes copies of its state to a separate Wheelhouse process over an authenticated debug association. What the debugger may do and what data it may see are checked as two separate questions. Scene overlays and service panels draw the same typed facts.
Two update paths: live generations and staged nodes
MTK updates running software along two paths. Trident source and configuration changes publish a validated application generation that goes live between calls. Runtime and driver changes move through a staged node rollout, with every transition recorded and the previous generation kept for rollback.
Read overview System BoundariesNames and layers that show who owns code
MTK names every file, folder and declaration for the system and layer that owns it. Dependencies point one way: core mechanisms, then Trident libraries, then applications, then products. A lower layer never depends on application policy, and the build refuses an include or a reach that points the wrong way.
Read overview Security and TenancyDeny-by-default checks at every boundary
Every request in an MTK deployment crosses five boundaries: identity, application, tenant and data, service, and device. Each boundary starts from denial and admits only what a declared grant names. A request stops at the first boundary that refuses, and the refusal names that boundary.
Read overview Coordinated DeliveryParallel changes with an owner and proof of landing
Every change has a claimed owner, its own worktree, the checks its files need, and a verified landing on main. A change is done only when its commit is an ancestor of main. People and AI-assisted lanes follow the same rules and leave the same record.
Read overviewProject scope
Inputs, targets, and acceptance checks.
Define the input data, target devices, required behavior, failure cases, and evidence before the pilot starts.
Contact us