Engineering inside ARMORY /
The data model, constraints and recovery decisions behind ARMORY.
A mineral-green asset workbench pairs a large interactive 3D stage with an object inspector and collection shelf. Three original GLBs can be inspected and downloaded from the public interface.
Interface and interaction architecture
Three.js powers the public object stage; the private workspace also includes a separately bundled model-viewer surface. Real stored asset versions and delivery manifests remain in the full-stack workspace.
Validation precedes the library version
The version command requires a validated self-contained GLB 2.0 file. It reads the embedded document to report mesh, material, node and animation counts, byte size and embedded-resource status. This is a bounded import contract. It avoids suggesting that every arbitrary 3D format or external texture package can enter the library unchanged.
Collections select versions
A collection stores selected version records, including their file digests and rights statement, rather than resolving each asset’s newest version during download. Version identifiers must be unique and belong to the current workspace. This distinction prevents a routine library update from silently changing a previously assembled production delivery.
Downloads check original-byte integrity
Bundle generation retrieves the stored file, recalculates its SHA-256 digest and compares it with the collection’s recorded digest. A mismatch stops the download with an integrity error. The ZIP manifest includes each path and checksum. A 20 MB aggregate bundle cap keeps the current delivery operation bounded and asks larger collections to be split.
Rights remain an explicit declaration
The asset record requires a rights confirmation and a textual licence or rights statement. Each version carries that declaration into the delivery manifest. The system preserves what the owner supplied; it does not infer commercial permission from file structure or attractive previews. Workspace authorisation is checked when original files are retrieved for delivery.
Operating the product
Start with the public interface to explore the design using example records. These interactions stay in the current view. Open the private workspace from the interface to use the existing account, storage and product workflows.
Resolve missing or external dependencies in the authoring tool and export a self-contained model before uploading.
Create a new version for a revised file instead of expecting an older delivery to follow the latest asset.
Split a collection if its combined model bytes exceed the delivery cap.
If an integrity check fails, retain the failed record for investigation and recover the intended original file before retrying.
Keep the bundle manifest with the models so recipients can identify versions and verify checksums.
Independent by construction
ARMORY has its own application source, build configuration, local server, database, object store and session cookie. The fifteen applications reuse copies of a common foundation, but their operational data and credentials are independent. A shared dependency cache on this Mac saves disk space; each product includes a lockfile and a command to install its own dependencies.
Mutations validate the workspace and current record version. Approval binds the reviewed content digest; an idempotency key prevents an identical retry from becoming a second action. These controls are implemented in the server, alongside the product-specific rules described above.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief