Registrar, ThingMake, and Arsenal boundaries¶
This page records the current separation between tenant manufacturing workflows and platform certificate governance. Older designs placed registrar approval in Arsenal and used ThingHub as the model/provisioning backend; that architecture is retired.
Current ownership¶
Concern |
Owner |
Console |
|---|---|---|
Device model descriptor |
ThingMake |
ThingMake / Models |
Registrar and factory-service relationship |
ThingMake |
ThingMake / Registrars and Factory integrations |
Thing manufacturing lifecycle and provisioning run |
ThingMake |
ThingMake / Things |
Repository, scope, placement, access grant |
ThingHub |
ThingHub |
Certificate authority and certificate governance |
ThingMint |
Arsenal (platform admin) |
Arsenal does not edit tenant registrars, models, repositories, or things. ThingHub does not create models or drive provisioning. ThingMint does not become a tenant console application merely because its governance surface is shown in Arsenal.
Registrar model¶
A registrar identifies the manufacturing authority for a set of things. It has a stable ID, account ownership, name/display metadata, state, and configuration. A factory service references the registrar and a ThingMake model.
Registrar creation is a tenant operation authorized by a DotID action on the account-scoped resource. Cross-account visibility is not inferred from registrar ownership; ThingHub repository/scope grants determine what another account can access.
Factory service model¶
A factory service is an account-owned, non-human integration with:
registrar and model references;
a role describing the factory callback responsibility;
an HTTPS endpoint and health state;
a one-time AK/SK credential for signed public-API calls.
The service is not a workforce user and cannot receive console access. Creating it does not create a workload identity for a deployed platform service.
Thing lifecycle¶
ThingMake owns the command and audit surface for provision, activate, deactivate, re-activate, and annihilate. Mutations are idempotent sagas. The accepted response identifies a provisioning run; clients poll or subscribe to the run/thing state instead of assuming synchronous completion.
ThingHub consumes the resulting thing identity for placement. It may not write the manufacturing lifecycle as a side effect of repository or scope operations.
Arsenal boundary¶
Arsenal is a platform-admin remote with three routes:
/arsenal/authorities— inspect and rotate the current intermediate authority;/arsenal/certificates— search, issue, and revoke certificates under approved platform procedures;/arsenal/audit— review certificate-governance events.
These operations use private admin browser routes and require platform-admin authorization. Tenant users never receive this surface. External certificate protocols remain on their published API/DDI contracts.
API ingress¶
Factory integrators use versioned public ThingMake routes at
api.flexgalaxy.ai, signed with FGAI-HMAC where specified.The ThingMake remote uses
/thingmake/api/through the private console gateway.Arsenal uses
/platform/arsenal/through the private admin gateway.
The browser and external routes can terminate in the same owner service, but their authentication, response projection, and compatibility contracts remain separate.