DEV Community: Whispart

Count Reports, Studies, and Outcomes Separately in an AI-Art Evidence Dataset

Whispart Studio — Wed, 21 Oct 2026 09:06:32 +0000

A dataset can contain 46 outcome records without containing 46 experiments. If your dashboard calls both “studies,” the code can execute perfectly while the conclusion is wrong.

Whispart's review manuscript on AI-art valuation provides a concrete example: 12 selected reports contain 25 study units and 46 outcome-family records. The useful engineering problem is preserving those units all the way from extraction to display.

Context and disclosure: Whispart develops selected GAN images into physical wall art. This article and the research workflow used substantive AI assistance. The manuscript is not peer reviewed; it is a purposive methodological review, not an exhaustive database of the field.

Keep the hierarchy in the data

In the downloadable evidence.json, reports contain studies, and studies contain outcomes. A report has a report_id; a study has a study_id and source_locator; each outcome has an outcome_id, construct, response_format and financial_consequence. That structure preserves the connection between a count and the passage it represents.

Figure 1 from Measuring Value in AI Generated Visual Art (20 October 2026 manuscript, not peer reviewed): classify the response format, perspective and financial consequences. This is a research diagram, not a GAN artwork.

The diagram separates the response task before counting it. “Worth,” a predicted selling price and a consequential bid should not be collapsed into one numeric value field. The response unit, perspective and payment rule carry meaning that a label alone cannot supply.

Reproduce a small part of the evidence map

Download the evidence archive from the Research page, extract it, and run this Python 3 snippet beside evidence.json. It uses the standard library and reads the supplied classifications; it does not infer classifications from the paper titles.

from collections import defaultdict
from pathlib import Path
import json

reports = json.loads(Path("evidence.json").read_text(encoding="utf-8"))
studies_by_family = defaultdict(set)
reports_by_family = defaultdict(set)
report_ids, study_ids, outcome_ids = set(), set(), set()

for report in reports:
    rid = report["report_id"]
    if rid in report_ids:
        raise ValueError(f"Duplicate report: {rid}")
    report_ids.add(rid)
    for study in report["studies"]:
        sid = study["study_id"]
        if sid in study_ids:
            raise ValueError(f"Duplicate study: {sid}")
        study_ids.add(sid)
        for outcome in study["outcomes"]:
            oid = outcome["outcome_id"]
            if oid in outcome_ids:
                raise ValueError(f"Duplicate outcome: {oid}")
            outcome_ids.add(oid)
            family = outcome["construct"]
            studies_by_family[family].add(sid)
            reports_by_family[family].add(rid)

print(len(report_ids), len(study_ids), len(outcome_ids))
key = "auction_bid"
print(len(studies_by_family[key]), len(reports_by_family[key]))

For the 20 October 2026 manuscript dataset, the output is 12 25 46, followed by 2 1. Two auction study units belong to one report. That second line is why a distinct report count matters: more study units do not necessarily mean more independent research programs.

Make the display preserve the distinction

Use explicit headings such as “Study units containing this family” and “Reports containing this family.” Families overlap, so their counts must not be stacked as mutually exclusive shares of 25. The records are measurement families, not a count of independent dependent variables or a pooled effect estimate.

The complete archive also includes reproduce_counts.py, which checks identifiers, JSON/CSV agreement and coverage scenarios. The short snippet above only demonstrates the counting units; it is not a substitute for those checks or for reading the original source passages.

Keep the object separate from the response

The Tree That Stayed — Whispart supplied framed-product presentation; GAN-generated artwork. Presentation image, not an installation photograph.

Where Silence Is Kept — Whispart supplied framed-product presentation; GAN-generated artwork. Presentation image, not an installation photograph.

These supplied product presentations of The Tree That Stayed and Where Silence Is Kept illustrate our studio context. They are not experimental stimuli from the reviewed reports. A response to a digital image and a decision about a specified physical framed work concern different objects and conditions. Store the object description and acquisition rule explicitly rather than assuming a shared artwork name makes the records comparable.

That distinction also applies to publishing metrics: page views, reactions, product visits and completed orders need separate event definitions. None is automatically evidence of the next. No conversion or pricing effect is estimated here.

Read the manuscript and download the evidence archive on Whispart Research to reproduce the counts and inspect the codebook. The classifications were prepared in one AI-assisted workflow without independent duplicate human extraction; computational consistency does not remove that limitation.

Figure 1 is the existing manuscript diagram. The two artworks are GAN-generated and shown in supplied framed-product presentations, not installation photographs.

Keep Artwork Files and Room Mockups Separate in a Publishing Workflow

Whispart Studio — Thu, 15 Oct 2026 02:35:57 +0000

A publishing workflow can upload the correct file format and still communicate the wrong thing. A room preview and a complete artwork might both be PNGs, both belong to the same collection folder, and both contain the same image. They make different claims when placed in an article.

That distinction matters at Whispart, where selected GAN creations become physical wall art and framed artworks. An artwork view lets a reader inspect the image. A digital room visualization lets them consider a possible presentation. If an automated publisher silently substitutes the second for the first, a useful preview can become a misleading stand-in for the work.

Start with the role, then resolve the file

One of our supplied artwork folders contains original-upscaled.png and scene-floating-wood.png. The names suggest different uses, but names alone are not evidence of origin. For this example, both files were visually inspected: one shows the complete artwork; the other shows it framed in a room. The supplied scene is treated as a digital visualization.

A small explicit manifest makes that decision available to a publishing script. The selector below requires the intended role instead of choosing whichever file happens to sort first. Set base_dir to the artwork folder before running it.

from pathlib import Path

assets = {
    "artwork": {"path": "original-upscaled.png",
                "role": "gan_original"},
    "room": {"path": "scene-floating-wood.png",
             "role": "digital_visualization"},
}

def select_asset(key, required_role, base_dir):
    asset = assets[key]
    if asset["role"] != required_role:
        raise ValueError("Asset role does not match placement")
    path = Path(base_dir) / asset["path"]
    if not path.is_file():
        raise FileNotFoundError(path)
    return path

artwork_path = select_asset("artwork", "gan_original", base_dir)
# Raises before file lookup: the room must not become the artwork.
# select_asset("room", "gan_original", base_dir)

This example was exercised against the local folder: the artwork selection resolved to an existing file, and requesting the room image as a GAN original raised the expected error. It is a minimal selector, not a claim that the whole publishing workflow runs unattended.

A failed match should ask for a decision

Do not catch that error and fall back to the first PNG. The failure is useful information: either the requested placement is wrong, the manifest is wrong, or the requested asset is missing. Check the file and correct the relevant record. A fallback would erase exactly the distinction the manifest was introduced to preserve.

A hash can establish that a later run has the same bytes you reviewed. It cannot establish that a room was physically built or that an image came straight from a model. Likewise, original-upscaled identifies a supplied artwork file here; it does not prove raw model-output resolution. Keep those claims separate from file identity.

Carry the distinction into the published page

The publication record needs the selected path, role and caption. For a room study, a useful caption is: Digital room visualization; not a photograph of a finished object or installation. The same label should survive the editor and appear beside the image. Hiding it in a local JSON file does not help the reader.

Before marking a post complete, inspect the actual public page. Is the complete artwork present where the text discusses its details? Is the room study identified where it appears? Did uploading or rearranging modules reverse their order? A technically successful upload answers none of those questions by itself.

Why the reader benefits

For someone considering art for a wall, these two views answer different questions: what am I looking at, and how might I imagine it in a space? Keeping their roles explicit lets the presentation support that decision without presenting an illustration as physical evidence.

The distinction is part of how we communicate Whispart's GAN-based wall artworks. If you would like to see the creative context behind the file examples, explore Whispart's artworks and studio approach. The same principle applies to other product workflows: asset selection should preserve the meaning of a view, as well as its pixels.

Written with AI assistance and checked against the supplied files. The code is a small standalone example, with the two selector outcomes described above tested locally.

A publishing timeout is not a failed post: keep an uncertainty state

Whispart Studio — Tue, 13 Oct 2026 07:02:46 +0000

A browser action can time out after the website has already accepted it. In a publishing workflow, treating that timeout as a failed post can turn a recovery attempt into a duplicate.

This matters for Whispart, where GAN artworks become physical wall art and the same source material is adapted for several publishing platforms. A completed article is useful; two accidental copies of it are not.

A draft address gave us the wrong clue

During a recent browser-run Tumblr publication, the saved draft had one identifier and the published post had another. Opening an address based on the draft identifier returned a missing page. The public profile, however, contained the completed article at a different address.

The recovery was to inspect the profile and verify the existing article, not create another post. The resulting forest study contains the two intended GAN artworks and their text. This is one observed case, not a claim that every platform changes identifiers on publication.

Give uncertainty its own state

Our local publishing helper keeps a ledger. It distinguishes a saved draft, an attempted submission, an unknown outcome, and a verified public article. Before the final browser action, it records submitting. If the run stops there, the next run sees an unresolved attempt rather than an empty queue.

When the result is unclear, unknown blocks automatic resubmission. Recovery has two paths: find and verify the existing public article, or inspect both the published list and the saved draft before recording that a retry is appropriate. Merely waiting longer is not evidence that the first submission failed.

Keep content identity separate from a run

A fresh run should not create a fresh identity for the same article. The helper checks a stable content identifier, a normalized title, a body-text hash, and, for newer editorial jobs, a claim key within the same platform and account.

These checks catch known repeats; they are not a semantic originality detector. Two substantially identical articles can have different titles and hashes. Editorial comparison is still needed, especially when an existing artwork supports a new article.

The helper also fingerprints the prepared text, tags and image metadata. If the local source changes after a draft is saved, that mismatch requires reconciliation with the remote draft. Changing the job name to escape the warning would discard the very connection recovery needs.

Verify the result outside the editor

A saved message proves less than a published article. Before recording success, the browser workflow checks the actual public permalink, author, complete body, loaded images, captions and intended links. The script validates the resulting evidence record; it does not independently see the browser or prove that an agent's observations are true.

This does not guarantee exactly-once delivery across a website we do not control. It provides a practical stopping point: when publication is uncertain, inspect before retrying.

For the artwork side of this workflow, Whispart develops selected GAN creations into physical wall art and framed artworks.

AI disclosure: this article was written by an AI agent from the local workflow implementation and recorded publishing observations. It describes a limited working process, not a benchmark or a guarantee about third-party platforms.

We looked through thousands of GAN images. Choosing one was the hard part.

Whispart Studio — Thu, 24 Sep 2026 09:29:04 +0000

The model had finished generating. That did not mean we had a finished artwork. In Whispart's studio workflow, it meant we had a much more difficult question: which image would still be interesting after the first two seconds?

We make images with a GAN model we call Mnemosyne. Our founder describes a working pattern with two very different kinds of looking. During training, the team reviews sample grids at saved checkpoints; after choosing a promising model state, it explores a much larger batch of outputs. Those numbers are approximate studio recollections, not a public benchmark or a recipe that every GAN project should copy.

The first question: when does more training stop helping the art?

In the founder's account, a model state may be saved at roughly 100-kimg intervals. Here, kimg measures thousands of real images shown to the discriminator during training (NVIDIA's StyleGAN2-ADA documentation). The studio uses about 50–100 fixed-seed examples to watch how the visual field changes. Fixed seeds make a comparison across checkpoints more meaningful: you can see what changes in the same starting positions rather than confusing a different sample with a different model.

But the comparison is aesthetic as well as technical. A later state can be more resolved while losing the surprising, half-formed relationships we value. That does not mean less training is universally better, or that a specific kimg value guarantees good art. For us it means the checkpoint is a choice, not a score that always goes up.

The second question: what survives a large batch?

Once a state looks promising, the studio may generate on the order of 10,000 candidate images. In the founder's description, two teammates first reduce that field to roughly 1,000 images that feel distinctive, compositionally alive, or worth imagining on a wall. The founder then makes a second selection of roughly 100. These are working estimates, not audited counts for the individual image below.

The first pass asks, “Is there something here?” The next asks, “Does it keep happening when I look again?” A clean thumbnail can fail the second question. A visually unstable image can pass because its composition leaves room for discovery.

Unnamed Heir is one selected Whispart work. The pale figure reads quickly. The dark ground and shifting edges take longer. The title offers a narrative opening without telling you whose heir this is or what she will do next. We are showing it as an example of the kind of image that rewards a second look, not as proof of an exact checkpoint or candidate count.

What we would want a review tool to preserve

If you build generative tools, here is the practical lesson from our process: the interface should help a human compare and return, not simply reward the output that wins the first glance. Keep checkpoint and seed identities attached to images. Make the full composition easy to open from a grid. Give “hold” its own state so an undecided image is not silently treated as a rejection.

And keep the final decision separate from generation. A model can produce a compelling possibility. People still decide what to keep, name, test in material form, and release. The Whispart process journal shows how those stages fit together.

What do you use to tell a generative system's most interesting outputs from its most immediately polished ones?

Published by Whispart. This article was drafted with an AI writing assistant using the founder's account and the studio's public process material, then checked against those sources. The figures above are approximate descriptions of a working pattern, not a claim about the provenance of the pictured artwork.

An honest wall-art preview needs two sizes

Whispart Studio — Wed, 09 Sep 2026 04:50:15 +0000

A wall-art preview can show the right image at the wrong scale. One common source of error is treating the artwork's image area and its framed outer dimensions as the same rectangle.

This matters to studios such as Whispart, where a selected GAN image is developed into a framed physical work. The frame, surrounding wall and viewing distance are part of the presentation. A preview should make those decisions visible enough for a viewer to reason about them.

Here is a small geometry model for a front-facing, schematic preview. All dimensions below are illustrative, not specifications for a Whispart product.

Store the outer dimensions explicitly

Suppose the visible image is 50 × 50 cm. A hypothetical frame adds 2 cm on each side, with no mat or gap:

outer width  = 50 + 2 + 2 = 54 cm
outer height = 50 + 2 + 2 = 54 cm

If the same design includes a mat, a float gap or a different overlap, that formula changes. A production product page should use confirmed outer dimensions rather than deriving them from an attractive border drawn in CSS.

For a 240 cm-wide wall represented by a 720 px canvas, the scale is 3 px per cm. The image area is 150 px wide; the complete framed object is 162 px wide. Placing the frame outside an element that already represents the outer size would count it twice.

Element	Real dimension in this example	Preview dimension
Wall width	240 cm	720 px
Image width	50 cm	150 px
Frame face, each side	2 cm	6 px
Complete framed width	54 cm	162 px

Preserve the artwork's aspect ratio

For a schematic component, keep the image and the surrounding frame separate:

<figure class="work">
  <img src="artwork.jpg" alt="Complete artwork preview">
</figure>

/* Example only: 3 screen pixels represent 1 cm. */
.work {
  box-sizing: border-box;
  width: 162px;
  margin: 0;
  border: 6px solid #6f5947;
}
.work img {
  display: block;
  width: 100%;
  height: auto;
}

With the square source image in this example, the content is 150 × 150 px and the outer object is 162 × 162 px. A non-square source keeps its own ratio; this snippet does not force it into a square opening.

The colored border is a schematic frame, not a photograph or material simulation. If a real frame overlaps the image, show the resulting visible area explicitly. Do not let object-fit: cover silently decide which part of the artwork disappears.

Say how the scale was established

A measured wall elevation gives a defensible scale for this simple model. An arbitrary room photograph does not. A sofa of unknown size is not a reliable measuring instrument, and perspective changes the apparent scale across a photograph.

When dimensions are unknown, call the image a styling illustration. When a preview is based on measurements, show the dimensions used and the limits of the model. A flat elevation does not predict a surface's texture, reflections or appearance in evening light.

Before deciding on a size, a viewer can mark the proposed outer rectangle on the wall with a suitable removable paper template, then look from the doorway and the usual seated position. This provides a physical scale check without pretending to reproduce the artwork's material presence.

The Whispart process journal treats framed-room visualizations as decision aids and physical proofing as a separate step. That is a useful boundary for preview design: help someone judge placement and proportion, while identifying which qualities the preview cannot demonstrate.

Published by Whispart. This article was drafted and checked by an AI assistant using Whispart's public process documentation. The component and measurements are teaching examples, not a deployed Whispart feature or a specification for an available artwork.

Print preflight for generative art: pixels, crop and physical proof

Whispart Studio — Wed, 09 Sep 2026 04:37:16 +0000

An image export can pass every file check and still fail as a physical artwork. For anyone building a generative-art export tool, separating those two kinds of approval makes the workflow easier to understand.

Whispart develops GAN-based images and gives selected works a physical form. Its process includes human curation, writing, material proofing and a release decision. The checklist here translates that published approach into practical preflight questions; it does not describe an existing automated Whispart print service.

Calculate resolution at the intended size

Pixel dimensions describe a file. Physical dimensions describe an object. The relationship is:

effective PPI = pixels along an axis / (print size in cm / 2.54)

For an illustrative 4096 × 4096-pixel image:

Square print size	Effective PPI, rounded
40 × 40 cm	260
50 × 50 cm	208
60 × 60 cm	173

These are arithmetic examples, not Whispart product specifications or pass/fail thresholds. A print provider should specify the file requirements for the actual process, material and intended viewing conditions.

If the image is cropped, calculate from the pixels that remain. If it is enlarged computationally, record both the original dimensions and the delivered dimensions. A larger pixel count does not by itself establish that the enlarged image contains convincing detail.

Changing only a file's resolution metadata does not add pixels. A useful export interface should therefore show the intended physical size beside the dimensions, rather than celebrating a “300 PPI” label in isolation.

Separate the front image from the edge treatment

A stretched canvas introduces a second geometry problem: what appears on the front, and what is reserved for the sides or finishing process?

Keep the approved complete image separate from any production derivative. Ask the fabricator for the actual allowance and edge treatment before exporting. Do not assume that every canvas depth or frame uses the same dimensions.

A review should make any crop visible. If a face sits close to the edge, a production allowance can change the composition even when the center looks identical. A preview that shows only the front rectangle can conceal that problem.

Give each check a truthful result

Check	What software can report	What still needs inspection
File opens	Decoding succeeded; dimensions read	Whether the image is the intended version
Size calculation	Effective PPI for the selected crop and size	Whether the print is convincing at the intended distance
Crop preview	Which pixels remain on the front	Whether the altered composition is acceptable
Color preparation	The file's declared profile and export settings	The result on the actual material under real light
Production proof	A proof record has been attached	Whether the proof deserves approval

“Check completed” and “approved” should be separate states. An export tool can flag missing information without pretending to judge an artwork.

Studio process photograph supplied by Whispart. It illustrates material inspection; it does not identify a particular GAN release or document a controlled print comparison.

Close the loop with the physical object

The Whispart journal's account of physical proofing distinguishes room visualizations from physical evidence. That distinction is especially useful when a website makes an artwork look complete before it has been printed.

Attach the inspected proof to the exact file version, intended size, material and date. Record a concrete observation—such as a distracting edge or lost separation in a dark area—and the next action. If the file changes, do not silently carry the old approval forward.

For a practice that authorizes one physical release of a selected image, the decision to release deserves its own record. A successful export is an input to that decision.

Published by Whispart. This article was drafted and checked by an AI assistant using the studio's public documentation. Numerical examples are illustrative; no specific printer, color accuracy or durability result is claimed.

Designing a contact sheet for GAN art review

Whispart Studio — Wed, 09 Sep 2026 04:19:15 +0000

A gallery of generated images has two different jobs: letting someone see the range of a model, and helping them decide which candidates deserve a closer look. A beautiful grid can do the first while quietly making the second harder.

This note comes from Whispart, a studio developing and curating GAN-based images for physical artworks. Our published process separates generated candidates from selected images and finished releases. The interface below is a design proposal based on that distinction, not a claim that Whispart has deployed a particular review application.

Preserve the comparison before adding a score

Begin with a stable contact sheet. Give each candidate a persistent identifier, preserve its complete composition, and keep the initial order recoverable. Avoid a masonry layout for the primary comparison: a tall tile occupies more screen space than a square one, which can influence what receives attention.

Equal-sized containers are useful, but equal-sized crops are a different decision. Use object-fit: contain for the review thumbnail so that the interface does not silently remove an edge or a figure. A detail crop can be a separate, clearly labeled view.

Let the reviewer toggle between three views:

View	Question it supports	Limitation
Complete contact sheet	Is there meaningful variation across this batch?	Small details are difficult to judge.
Single candidate, complete image	Does the composition hold together without its neighbors?	One image cannot demonstrate the range of a system.
Detail at a stated zoom	Is that mark deliberate-looking ambiguity or a distracting artifact?	Enlarged detail cannot decide the whole composition.

A high-resolution image should load when requested; the initial sheet can use smaller derivatives. Keep the same candidate identifier attached to both. A thumbnail and its full-size file must never drift apart because filenames were sorted differently.

Make “undecided” a real state

An unchecked image has not necessarily been rejected. A reviewer may not have reached it, may need a larger view, or may be postponing a decision until a series becomes clearer.

For a small tool, an illustrative record could look like this:

{
  "candidate_id": "study-017",
  "review_state": "hold",
  "observation": "The pale area competes with the figure at thumbnail size.",
  "next_check": "Inspect the complete image on its own.",
  "reviewed_at": "2026-09-09T04:00:00Z"
}

This is fictional example data. Its useful feature is the separation of observation from action. “Bad image” does not tell the next reviewer what to inspect. A bounded visual observation does.

Keep unreviewed, hold, shortlisted, and excluded distinct. Store a change history if multiple people can alter a decision. Shortlisting should not automatically authorize printing or publication; those are later decisions with different evidence.

Keep the studio's preferences legible

Whispart's approach values emotional tension, ambiguity and images that continue to hold attention. A default “sharpness” score would therefore be a poor substitute for the studio's judgment. Blur may matter to the image; a technically clean output may still be uninteresting.

For another practice, graphic clarity might be essential. The interface should let the reviewer state that preference instead of smuggling it into a universal quality number. Notes about visual structure, repetition and unresolved questions are more useful here than an unexplained score out of ten.

The Whispart process journal provides the concrete workflow behind this proposal: a visual field becomes candidates, then human selection, writing and material proofing determine what can become a physical work. A contact sheet supports the selection stage. It cannot supply all of the later decisions.

Published by Whispart. This article was drafted and checked by an AI assistant using Whispart's public studio documentation. The interface and example record are proposals, not reported production software or research results.

A seed is not a provenance record: documenting generative art outputs

Whispart Studio — Tue, 08 Sep 2026 04:03:35 +0000

A seed is useful when you want to revisit a generated image. It is much less useful when someone asks which checkpoint produced the image, whether the displayed file was cropped, or which candidate eventually became a physical work.

Those questions need a small chain of records: run → output → selected image → production file → physical proof. You can keep that chain in JSON files and a folder of evidence before you need a database.

This article proposes a lightweight record format for people building generative art workflows. The example is fictional and is not an export of Whispart's internal production system.

Give the run and the image different identities

Treat a run as the configuration used to generate a set of candidates. Give each candidate its own identity, even if it shares a seed with an image from an earlier experiment.

For the run, preserve:

The exact checkpoint file, with a checksum to identify its bytes.
The generation code revision and resolved configuration, including default values.
The software environment and relevant hardware information.
A dataset version reference, when you control the training process, with its source-review records stored separately.

For each output, record the run ID, sampling inputs and the actual exported file. Depending on the implementation, sampling inputs can include a seed, a saved latent vector, conditioning inputs or additional noise settings. Record what the particular generator consumes; don't assume a seed captures all of it.

Even a carefully recorded configuration is not a promise of identical pixels everywhere. PyTorch's reproducibility documentation explains that results can differ across releases, platforms and CPU/GPU execution. Keeping the original output file gives you a reference when a later rerun differs.

Record what happened after generation

Suppose a fictional studio selects candidate-0042, crops it for presentation and later exports a separate file for printing. If all three images are called final.png, the history becomes difficult to reconstruct.

Instead, preserve the original candidate and record each derived file with its parent and the operation performed. A crop changes the boundary of an image; an upscale changes its pixel dimensions. Neither operation should silently replace the original record.

Selection is a separate event. Record which candidate was selected, by whom, when, and why. A short, specific note is more useful than a generic quality score: for example, "Keep the uncropped image for review; the narrow crop removes the secondary figure."

This separation matters when generated images become physical objects. Whispart's illustrated GAN process distinguishes a model, an output, a selected image and an authorized physical release. It also distinguishes presentation mockups from physical proofing evidence. The record format below applies that distinction to file management; it does not imply that the studio uses this particular schema.

A small example you can adapt

The following is an illustrative record with unresolved fields, not a completed production record. Paths and IDs are invented. Replace them with actual files and computed checksums before relying on the record.

{
  "schema_version": 1,
  "example_only": true,
  "run": {
    "id": "demo-run-01",
    "checkpoint_file": "models/demo-checkpoint.pkl",
    "checkpoint_sha256": null,
    "code_revision": null,
    "configuration_file": "runs/demo-run-01/config.json",
    "environment_file": "runs/demo-run-01/environment.txt",
    "dataset_version": null
  },
  "output": {
    "id": "candidate-0042",
    "run_id": "demo-run-01",
    "seed": 42,
    "sampling_inputs_file": "runs/demo-run-01/inputs-0042.json",
    "file": "outputs/candidate-0042.png",
    "sha256": null
  },
  "presentation": {
    "id": "presentation-0042-a",
    "parent_output_id": "candidate-0042",
    "operation": "crop",
    "file": "presentations/candidate-0042-crop.png",
    "sha256": null
  },
  "selection": {
    "status": "pending",
    "selected_asset_id": null,
    "reviewer": null,
    "reviewed_at": null,
    "reason": null
  },
  "production": {
    "source_asset_id": null,
    "print_file": null,
    "print_file_sha256": null,
    "proof_photo": null,
    "proof_result": "not_reviewed",
    "release_id": null
  }
}

Notice that the presentation crop exists while selection is still pending. Making a mockup does not automatically approve that crop for production.

Here is a concrete way to use the example:

Compare the original output with the presentation crop. If the original is selected, set selected_asset_id to candidate-0042; if the crop is selected, use presentation-0042-a. Save the reviewer, time and actual reason.
Export the print file from the selected asset. Record that asset's ID as production.source_asset_id, and compute the checksum of the exported print file.
When a physical proof is made, attach a photograph of that specific proof and record the review result. If it fails, preserve the failed attempt and create a new production attempt rather than overwriting it.
Assign a release ID only when the studio's release decision is complete. Keep any edition policy in a separate, explicit record.

A room visualization can help you assess scale, but it belongs with presentation material. It cannot fill the missing proof_photo field.

Check the relationships before you trust the record

Start with a few checks that catch ordinary mistakes:

Does every referenced file exist, and does its current checksum match the saved value?
Does each derived asset point to the actual parent used to create it?
Does the production file trace back to the selected asset?
Does the proof evidence identify the same production attempt?
Are unresolved fields still visibly unresolved?

A checksum helps detect a changed file. It does not establish who created it, whether a source was appropriate to use, or when an event occurred. Keep source-review notes and dated decision records alongside the files, with version history or another audit trail appropriate to your needs.

If you retain only one thing from an exploratory session, keep the actual output and its run reference together. That makes the next decision—regenerate, compare, select or prepare for print—possible without reconstructing the session from memory.

Published by Whispart Studio. This article was generated by an AI agent using the linked source material. The example schema is proposed guidance, not a claim about a deployed studio system.