Skip to content
Moduloa
← Five projects, one foundation
MOD-01 · Project 5 of 5

TOUCHMARK: APIs and the unit record

Three tasks

TOUCHMARK · for the record. Every unit marked, and traceable to how it was made.

Every part, step and test of every unit would be recorded, and the customer would reach that record behind a sign-in and by API, with nobody at Moduloa in between. A complaint would be settled against the record, traced to the step, part and blueprint revision behind it, and corrected in the blueprint for every hub that runs it.

Why the name. London pewterers struck their mark on every piece and on the guild's touchplate, so each one could be traced to its maker.

Why it matters. The record is what a customer keeps after the shipment: proof of what was built, and a way into their own systems. It is designed to be the customer's data.

The shadow system it is designed to replace. A complaint log kept on the side, an unofficial quality sheet, the status deck, and the same data keyed in a second time on the customer's side. In the design, one unit record would be written by the run itself and read by the customer's own ERP, MES or quality system through an API, without replacing it, and a complaint would enter that same record and be traced to the step, part and revision behind it.

Research behind it, some. The ERP has already reached down for it · The hidden factory is an office · The standards landed below the work The marking page sets its rules out with sources, and the notes reach the record from the robot side. Nothing yet covers complaints or customer APIs head-on, and no API definition is published.

On the site: The record · The marking requirement · Quality · Learning

Stage 0 · nothing is built · three open tasks · reviewed 5 October 2026

Inside it

What it is made of

The pieces of the work that live in TOUCHMARK. Each is written as designed: none of it runs yet.

Traceability and identity

One code per part, a tree of codes per unit (R-02).

Every part would arrive with one code that resolves to supplier, part, revision and lot or serial, and every closed sub-assembly would get its own code, so each unit's record becomes a tree of physical identities. The rules borrow from schemes already in force: GS1 Digital Link and IEC 61406 for the identifier, the medical device identifier (UDI) for when to serialise and when a lot is enough, and the EU's July 2026 product passport standards for the format. The rules are written on the marking page; the resolver that would apply them is not built.

Suppliers mark their parts under PYX, and the floor mints a code for each closed sub-assembly under JACQUARD.

On the site: The marking requirement, with its sources

Sources GS1 Digital Link · IEC 61406-1: Identification Link · EU MDR: UDI · CEN/CENELEC: DPP standards in the Official Journal, July 2026

APIs to customers' ERP and MES

The read API and its mapping (R-01).

The unit record would be readable by API, so a customer's own ERP, MES or quality system can take it in with nobody at Moduloa in between. The vocabularies exist: ISA-95, published internationally as IEC 62264, defines the boundary between business systems and production control; the Asset Administration Shell (IEC 63278-1, 2023) gives an asset one standard digital form and publishes its own API specification; IPC-2591 CFX does the same job for electronics assembly equipment. The inbound side already has a published schema; the outbound API has not been written.

On the site: Transparency as a product feature

Sources ISA-95 / IEC 62264 · IEC 63278-1:2023 · IDTA, Asset Administration Shell specifications · IPC, CFX

Complaint to correction

From complaint to fix, with response time on record (R-03).

Every complaint would enter the quality system with its response time on record, be traced to the step, part and blueprint version behind it, and be closed by a correction that reaches every hub running that blueprint through change control, validated at each site. This is the discipline regulated industries already require: US medical device rules make each investigated complaint's record name the correction or corrective action taken, on top of ISO 13485's complaint-handling clause. None of it runs yet, and response times are not set.

The fix itself is the next JACQUARD revision.

On the site: Boring on purpose · The run teaches the blueprint

Sources 21 CFR 820.35 · FDA, Quality Management System Regulation

The work

Tasks

Several people can work on the same task, each with its own deliverable. Ask to commit with the link on a task: name what you will deliver and a date no more than three months after it is accepted.

R-01Open

Unit record read API v0.1

Done when
An OpenAPI 3.1 file returns one EX-100 unit's record as the execution page traces it: its parts with lot or serial, its steps and its tests, and the tree of closed sub-assemblies (marking rule M-06), with a section on who may read what.
Stretch
Each field mapped to an ISA-95 object and a candidate Asset Administration Shell submodel.
Effort
Two to three weeks, part time

Ask to commit to R-01 →

The honest limits

What is open, and what would prove it

  • The unit record and its API are described, not specified: no API definition is published. R-01 writes the first.
  • The resolver that turns a part code into its record does not exist, and its distribution and access models are future work (marking rule M-07).
  • Three pages name whoever does a step three ways: operator, executor, operator or robot. The factory OS data model picks one.
  • Who owns an improvement learned from a customer's units is open on the learning page.

On the register

  • P-18 · due 31 December 2046 · open · the lasting advantage is the framework: standards, data, certification, training
← 4 · JACQUARDCHARTER · the factory OS →
Reviewed 5 October 2026 · next review by 2 November 2026 · Questions go to seat 001, the founder · Corrections welcome
Ask Datum