Mathias Petersen Let’s talk ↗
MATHIAS//PETERSEN
← Project index

Modular field-operations software / 2026 to present

Asset Operations Platform

Why it matters Adding a new field workflow should not require rebuilding authorization, offline queues, evidence handling, audit, and deployment.

The project began as one asset tracker; repeated needs across inventory, site commissioning, media, support, and reporting exposed a platform problem.

Asset Operations Platform project
StatusActive development · pre-beta
Role in the architectureApplication platform + offline field workflows
My roleFounder & Lead Engineer
DisciplinesSystems + tools / Infrastructure
01 / Product interface

One system, shaped around the operator’s context.

These are responsive visual-conformance fixtures from the working product, showing the workspace, inventory, and phone-first capture flow.

Asset operations workspace overview
Authorized workspace projection
Inventory operations interface
Desktop inventory workflow
Mobile asset capture workflow
Phone capture flow
02 / The work
Challenge

Operational software tends to split into brittle one-off apps: each rebuilds identity, scoping, offline behavior, evidence handling, audit, deployment, and integrations.

Field teams face unreliable connectivity while administrators inherit duplicated policy, inconsistent data paths, and a full-stack release for every new workflow.

Approach

I separated domain applications from platform guarantees.

Applications declare versioned records, queries, operations, navigation, and presentation, then add custom Svelte or compiled Rust only where the workflow needs it. A provider-neutral kernel enforces access and transaction rules, while blueprints, capability contracts, and provider ports compose the installed workspace and deployment.

03 / Architecture model Application platform boundary

Domain workflows inherit platform guarantees.

Applications define operational language, navigation, records, queries, and named mutations. Shared capabilities and one provider-neutral kernel supply the hard guarantees, while deployment adapters can change without forking the apps.

Asset Operations PlatformSystem boundary
  1. 01 Operator workspace

    Projected routes · tasks · contexts · offline eligibility

  2. 02 Installable applications

    Asset capture · inventory · commissioning · media · reporting

  3. 03 Shared capabilities

    Scanning · records · files · jobs · collaboration · reports

  4. 04 Rust kernel

    Auth · scope · contracts · idempotency · atomic state · audit · outbox

  5. 05 Provider ports

    SQLite / filesystem · PostgreSQL / S3 / NATS · native cloud adapters

Extension pathDeterministic and fail-closed
  • Manifest compiler
  • Version + digest pins
  • Signed application package
  • Sandboxed custom UI
Offline pathCorrectness beyond a cached shell
  • Encrypted command queue
  • Evidence uploads first
  • Conflict + retry state
04 / Implementation

The decisions beneath the summary.

01

Application boundary

Let domain applications own their language while the platform supplies the expensive cross-cutting guarantees.

An application declares records, queries, named operations, navigation, presentation, and required capabilities, then adds custom Svelte or compiled Rust only where its workflow is genuinely different. Asset capture, inventory, commissioning, media, reporting, scheduling, budgeting, support, and site work all exercise this boundary instead of becoming separate full-stack products.

  • Applications own domain names, workflows, validation, and custom interfaces
  • Shared capabilities cover records, scanning, files, collaboration, jobs, reports, and other reusable behavior
  • Deterministic manifest includes, canonical compilation, hashing, signing, and exact version pins make a package reproducible
02

Context-shaped workspace

Project only the routes and work an authenticated operator can actually use.

Versioned blueprints provision a site or team and install the compatible application surfaces plus their intersected roles. At sign-in, the kernel produces one permission-filtered workspace containing only the routes, tasks, operations, context shortcuts, and offline eligibility that operator may use. Adding a work area becomes an audited change instead of a rebuild of one global registry.

  • Authorization binds subject, application, mount, context, operation, and policy version
  • Provider-side row predicates and field projection prevent the browser from receiving data it should later hide
  • Signed page cursors are tied to the operator, scope, query, policy, and version, so a cursor cannot be replayed in another work area
03

One mutation boundary

Commit state, evidence, audit, idempotency, and follow-up work as one authorized operation.

Applications expose named domain operations rather than writing tables directly. The kernel authenticates and scopes the request, checks schemas and expected record versions, then creates a bounded storage plan. Records, immutable observations, relations, audit, retry identity, and follow-up effects commit together so a reconnect or integration cannot observe half a change.

  • Operation plans are bounded before they reach SQLite, PostgreSQL, or another state provider
  • Retry identity and audit share the transaction boundary with the domain state they describe
  • Integration workers receive identities limited to an exact operation, application, work area, and context instead of database credentials
04

Offline as correctness

Queue only operations whose ordering, ownership, evidence, retry, and conflict behavior are explicit.

The browser maintains a bounded owner-scoped encrypted command queue and a separate encrypted file queue. Evidence uploads complete before dependent mutations are released; dependency order survives reconnect; backoff and retry state is visible; stale versions become operator-facing conflicts instead of silent last-write-wins updates. The result is an offline workflow contract, not only a cached application shell.

  • Operation metadata decides whether a command is eligible for offline execution
  • Files and commands have separate queues so evidence dependencies can be satisfied deterministically
  • Conflict, retry, blocked, and completed states remain visible to the field operator
05

Portable deployment and safe extension

Substitute providers beneath contracts and keep runtime-installed code outside the trusted application origin.

Local filesystem, SQLite, and database queues can run an appliance; PostgreSQL, S3-compatible storage, and NATS support service deployments; AWS, Azure, and GCP adapters implement the same blob, dispatch, and secret ports. Unselected providers perform no credential discovery or background work. Runtime-installed custom UI is digest-verified, opaque-origin, no-network, and mediated through a narrow host API rather than being given the trusted application origin.

  • The same application contracts span single-machine, Docker, and replicated Kubernetes distributions
  • Compatibility checks fail closed before an app package is activated
  • Runtime native and WASM application backends are deliberately excluded; installed extension is constrained to the safer UI boundary
05 / Tradeoffs + limits

What this work does not claim.

01

The platform is actively developed and pre-beta; it is not presented as a deployed production system.

02

Native-cloud live conformance is credential-gated, and no ERP or vendor-specific connector is bundled.

03

The query system is deliberately bounded and declared; it does not claim arbitrary universal full-text search.

04

Performance tests exercise defined synthetic paging and policy workloads; they are regression evidence, not production latency or capacity SLAs.

06 / Engineering review

Architecture, evidence, and limits.

Architecture

  1. 01
    Applications over shared capabilities

    asset, inventory, commissioning, and reporting keep their own workflows while reusing records, scanning, media, collaboration, jobs, and reports

  2. 02
    One mutation boundary

    authorization, validation, retry identity, version checks, state, audit, and follow-up effects commit together instead of drifting across handlers

  3. 03
    Blueprint-provisioned work areas

    creating a site or team automatically installs the compatible applications and intersects their roles with that context

  4. 04
    Offline as an operation contract

    only eligible commands queue, evidence uploads before dependent work, and stale versions become explicit operator conflicts

  5. 05
    Provider ports below application contracts

    the same operations run on local SQLite or service PostgreSQL, with storage and queue providers selected at deployment

  6. 06
    Extension without shared trust

    installed custom UI is signed, digest-checked, isolated from the main origin, and limited to approved operations

Validation

  1. 01

    Responsive fixtures exercise every bundled workflow across phone, tablet, desktop, themes, zoomed text, reduced motion, permissions, offline operation, errors, and large results

  2. 02

    Synthetic PostgreSQL datasets are used to catch unbounded paging and field-policy projection; these are regression workloads, not production capacity claims

  3. 03

    The fast gate checks Rust, every Svelte package, version policy, and Kubernetes distribution drift concurrently

  4. 04

    The full gate adds workspace tests, production builds, browser workflows, and disposable PostgreSQL and object-storage conformance

  5. 05

    Pre-beta status and credential-gated cloud checks remain explicit; an unavailable provider fails closed instead of silently selecting another backend

07 / Project consequence

Why it matters in practice.

  • 01New field applications inherit access control, audit, evidence handling, and offline behavior instead of creating another full-stack silo
  • 02Local SQLite appliances and PostgreSQL-backed services execute the same application operations, avoiding separate product logic for each deployment
  • 03Permission-projected workspaces keep unauthorized routes, fields, and operations out of the browser response instead of merely hiding controls
  • 04Offline evidence uploads complete before dependent commands, while stale edits become visible conflicts instead of silent overwrites
My ownership
  • Platform and application architecture
  • Rust kernel, capabilities, and provider interfaces
  • Svelte SDK and responsive workflow surfaces
  • Offline synchronization and evidence transfer
  • Release, conformance, and deployment automation
Built with
  • Rust / Axum
  • Svelte 5
  • SQLite + PostgreSQL
  • Signed application packages
  • Docker / Kubernetes
  • Cloud provider adapters