Adam.

The model was only
one part of the product.

An image-to-3D model can produce an attractive shape while the application around it still fails. Users need a straightforward upload, clear job behavior and files they can retrieve. Shared GPU hardware adds another requirement: heavy jobs must not overlap or interfere with neighboring services.

Adam began as a local Hunyuan3D 2.1 shape-generation workflow on an ASUS GX10 with NVIDIA GB10 hardware. OpenWebUI supplied a familiar browser interface. A Python API added image preparation, job orchestration, geometry processing and attachment delivery around the pretrained model.

My role: decide what working means

I directed requirements, hardware and runtime choices, implementation, visual review and acceptance. AI-assisted engineering supported development and testing. I retained responsibility for evaluating the evidence and authorizing changes to the working environment. Adam integrated an established model; it did not train a new foundation model.

A completed process
was not enough.

The initial implementation established local generation and STL and GLB downloads. Later versions explored image preparation and geometry profiles. By October, a reproducible failure exposed a lifecycle defect: an output-directory error could leave the earlier APIs locked against new jobs.

V3 consolidated the useful paths into one bounded worker container per job. Separate preparation, inference and postprocessing subprocesses run in sequence, with each heavy stage exiting before the next. Earlier successful paths launched two containers in V1 and three in V2.

The benefit was a simpler, more inspectable lifecycle. The measured comparison did not establish a substantial speed or memory improvement.

Bound the work.
Keep the interface familiar.

Uploads pass size and pixel checks before foreground and transparency preparation. The pinned local Hunyuan runtime generates a shape. Geometry processing then scales and grounds it, evaluates its properties and exports STL and GLB files for the interface to publish as attachments.

A host lock protects setup, while an atomically named worker makes an active job detectable even if the API restarts. A second request is rejected while that worker is active. On timeout, the controller stops the positively identified owned worker before releasing admission.

Offline dependencies and resource bounds

The application bounds uploads, job duration, resource use and worker logs. Generation runs with networking disabled and pinned local model assets. An initial isolated failure revealed a missing background-removal dependency. Staging that asset explicitly made the documented offline runtime complete; assuming that model weights alone were sufficient would have missed it.

Compatibility mattered during the cutover

The change retained the existing UI address and attachment contract. Earlier code, model dependencies and outputs stayed available for recovery. Compatibility tests checked old-file downloads, unauthenticated file access remained restricted, and shared services were checked for preservation. This is a documented cutover boundary, not a fresh security audit of the running service.

Inspect the files.
Not just the preview.

The following results come from retained implementation and October 19 acceptance records. They were not rerun against Adam as part of building this website.

The isolated comparison completed six serial generation jobs across three versions and two synthetic fixtures. All twelve STL and GLB exports were reopened independently. Checks covered finite coordinates, reported face counts, a requested 150 mm maximum dimension, grounding, watertightness and winding consistency.

I accepted the V3 visual profile. Production preparation then passed thirteen controller and five geometry regressions. Worker drills covered timeout handling, resource stops, bounded logs, admission across an API restart and protection of unrelated workers.

What a valid mesh still does not prove

A watertight mesh can contain geometric defects or invented details. Two fixture comparisons do not establish broad repeatability. No physical printing or precision CAD accuracy was demonstrated in the cited cutover. A downloadable STL is an output artifact, not a guarantee that the result is fabrication-ready.

Exercise the real interface.
Prove a way back.

Acceptance included actual authenticated jobs through the existing application, not only direct model calls. The rollback was exercised by generating through the original V1 route, rather than merely keeping its code on disk.

First V3 bottle: 129.91 seconds. Both attachments appeared in the interface, and I confirmed downloading the pair.

Original V1 rollback bottle: 102.60 seconds. The retained original route completed a real generation.

Final V3 robot after restart: 103.51 seconds. Both attachments appeared and matched their backend hashes.

All six attachment copies from those three jobs matched backend SHA-256 hashes. The final V3 service was active and startup-enabled on October 19; the earlier APIs were stopped and retained.

These timings are not a speed ranking

The jobs used different fixtures and generation profiles, so their times are not like-for-like performance comparisons. The records establish dated generation, attachment and recovery milestones. They do not establish uninterrupted operation since October 19, a cold-boot test or a complete backup-restoration rehearsal.

Make the lifecycle reliable.
Keep the claims bounded.

Adam demonstrates application integration around generative AI: GPU deployment, Python orchestration, explicit admission control, dependency preparation, geometry inspection and verifiable file delivery. The strongest improvement was a more inspectable lifecycle with an exercised rollback path, not a claim that a model had become a precision design tool.

Broader input testing, physical fabrication checks and full recovery validation remain separate questions. An appealing visual result should not erase uncertainty about geometry, hidden surfaces or dimensional fidelity.

Illustration and confidentiality boundary

The diagrams here are original conceptual explanations. They are not actual uploaded inputs, generated models, interface screenshots or evidence of a physical print. Private network details and operational destinations are omitted. The source case-study PDF remains private writing material, not a download.