A small JSON handoff for a custom figurine from a photo

Formacara — Sat, 03 Oct 2026 09:05:35 +0000

A rendered preview and a printable model answer different questions. The preview communicates appearance; the production file must also match an agreed size, material and version. If those facts live only in a chat, it is easy to lose track of which revision a customer actually approved.

Here is a lightweight data model for keeping that handoff explicit. This is an illustrative design proposal, not a claim about Formacara's deployed software.

Store the agreement, not just the latest filename

{
  "projectId": "example-figurine-001",
  "modelVersion": "v03",
  "references": [
    { "assetId": "ref-front", "purpose": "likeness" },
    { "assetId": "ref-side", "purpose": "pose" }
  ],
  "specification": {
    "heightMm": 150,
    "material": "PLA",
    "colourMode": "single-colour",
    "pose": "standing, arms close to body"
  },
  "visualApproval": {
    "status": "pending",
    "approvedModelVersion": null
  },
  "productionReview": {
    "status": "pending",
    "reviewedModelVersion": null
  }
}

The 150 mm height is an example value, not a product specification. Replace it with the agreed dimension. Asset identifiers point to references without embedding photographs or public download links in the record.

The useful detail is the version beside each approval. A boolean such as approved: true does not explain what was approved. If the pose changes after review, the old approval should remain associated with the old version.

Make version changes visible

One possible release condition is:

visualApproval.status == "approved"
AND visualApproval.approvedModelVersion == modelVersion
AND productionReview.status == "passed"
AND productionReview.reviewedModelVersion == modelVersion

This is a workflow condition, not a geometric test. A matching version does not prove that thin features are strong enough or that supports can be removed cleanly. Those checks still belong to the person preparing production.

When a model changes, avoid silently carrying approvals forward. Show the previous decision in the history, mark the new revision as awaiting review and identify what changed. Even a short note such as “right arm moved closer to torso” gives the next reviewer a useful starting point.

Distinguish missing information from permission to improvise

A photograph may not show the back of the subject. That is missing evidence, not automatic approval for any reconstruction. Add an explicit note for interpreted details, or request another reference before proceeding.

The interface can present the same information in plain language: “This preview uses model v03, at the agreed height, in single-colour PLA.” The customer does not need to see JSON. They need to understand which appearance, pose and material their decision covers.

Keep the record small

Do not put payment data, unnecessary personal information or photographs into a handoff that only needs asset references and design decisions. Decide who needs access to the source images and keep that separate from a broadly shared production checklist.

For context on the customer request behind this example, see Formacara's custom figurine from photo overview. A clear brief connects that request to production without implying that a digital preview is identical to a physical print.

Published by Formacara with AI assistance. The schema and identifiers above are illustrative. They contain no customer data and describe a proposed workflow, not a tested production system.

DEV Community: Formacara

A small JSON handoff for a custom figurine from a photo

Store the agreement, not just the latest filename

Make version changes visible

Distinguish missing information from permission to improvise

Keep the record small