DEV Community: TANCYBOX

The Window Problem: Modeling a Transparent Aperture in a Packaging Spec

TANCYBOX — Thu, 05 Nov 2026 08:51:40 +0000

The earlier articles in this series covered geometry, curved forms, multiple cavities, and material wrap. All of them assumed one thing without saying it: the product is hidden until the box opens.

A window breaks that assumption. The moment you cut a transparent panel into a case, the product becomes permanently visible — and a dozen new constraints arrive with it.

A window is not a hole

In a spec, aperture sounds like a cutout. It is not. A hole removes structure; a window removes structure and adds an optical element. Five properties matter, and none of them are length or width:

type WindowAperture = {
  shape: 'rect' | 'ellipse';
  material: 'glass' | 'acrylic';
  thicknessMm: number;        // 2–3 for glass, 3–5 for acrylic
  transmissionPct: number;    // optical clarity; cheap acrylic yellows
  sealed: boolean;            // gasket vs open edge
  recessedMm?: number;        // set back from the surface, or flush
};

Choosing glass buys clarity and scratch resistance, and costs weight and fragility. Choosing acrylic buys impact resistance, and costs clarity over time — most acrylic yellows, and a yellowed window on a €200 case is a defect, not a patina.

The binding constraint: the interior is now a stage

This is the part that gets missed, and it is not a materials question at all.

Once the product is visible from outside, the interior layout is no longer free. You can't place a cavity wherever it fits — you have to place it where it reads through the window.

In the case shown, the window sits in the lid, and the interior holds a bottle plus two glasses. That layout only works because the bottle is positioned so its label faces the glass, and the glasses sit in the corners where they frame it rather than block it.

Put that as a rule:

// Every cavity must be at least partially visible through the aperture.
for (const cavity of spec.cavities) {
  if (!overlaps(cavity.projectedRect, spec.aperture.rect)) {
    errors.push(
      `cavity "${cavity.id}" is invisible through the window`
    );
  }
}

If your spec can express "hidden from view", the same schema can catch a cavity that no customer will ever see.

Three failure modes that only exist with a window

Misting. A sealed case with any residual humidity fogs the inside of the glass in transit. Either vent it or control the assembly environment — both are process specs, and neither appears in a render.
Breakage under drop. Glass in a lid is the furthest point from the impact edge and the most fragile element in the assembly. A recessed window survives drops that a flush window does not.
Glare. A flush, highly polished window reflects more than it transmits under retail lighting. Recessing it by a couple of millimetres changes what the customer actually sees.

The pattern, five articles in

1 — separate universal fields from variable ones.
2 — geometry lives in a profile.
3 — repeated objects live in a list.
4 — the material owns part of the spec (wrap).
5 (this one) — an optical element constrains the interior layout, not just the surface.

The recurring lesson: every element you add to a box doesn't just add a field — it adds a constraint on the fields you already had.

A window is the clearest example, because it silently converts the inside of your packaging from storage into staging.

The case shown is a windowed wooden wine case from TANCYBOX — glass panel in the lid, molded interior for one bottle and two glasses.

Fitting Three Objects in One Case: Modeling Multi-Item Packaging

TANCYBOX — Thu, 29 Oct 2026 06:54:17 +0000

The first article in this series modeled a product as a data model. The second one dealt with a curved object that broke the rectangular assumption.

This one is worse: a case that holds three objects — one bottle, two champagne flutes — each with a different shape, a different tolerance, and its own cavity. And they all have to share one outer envelope.

Here is what that does to the schema.

The single-item model stops working immediately

The earlier model had one dimensions block and one interiorProfile. For a multi-item set, "the interior" is not one thing — it is a layout.

The naive fix is to add fields: bottleCavity, fluteCavityLeft, fluteCavityRight. That works for exactly one configuration and collapses the moment a client asks for two glasses instead of one, or a wider bottle.

The better fix: model cavities as a list.

type Cavity = {
  id: string;                 // 'bottle', 'flute-left', 'flute-right'
  holds: 'bottle' | 'flute' | 'accessory';
  inner: Dimensions;
  clearanceMm: number;        // how much room around the object
  position: 'centre' | 'left' | 'right';
  orientation: 'upright' | 'lying';
};

type MultiItemSpec = {
  envelope: Dimensions;
  wallThicknessMm: number;
  cavities: Cavity[];
  sharedToleranceMm: number;
};

Now the configuration is data. Two flutes, one flute, three miniatures — all the same schema.

The constraint that actually matters

With one item, the only check is "does it fit". With multiple items, the constraint is additive:

sum(cavity widths) + dividers + 2 × wallThickness  ≤  envelope width

That sounds obvious, but it is the check that gets skipped, because each cavity is designed independently by a different person. The bottle cavity is specced by the packaging engineer; the flute cradles are specced by the structural designer. Nobody runs the sum until tooling is quoted.

Here it is as a validator:

function validateMultiItem(s: MultiItemSpec): string[] {
  const errors: string[] = [];

  const totalCavityWidth = s.cavities.reduce(
    (sum, c) => sum + c.inner.widthMm + c.clearanceMm * 2,
    0
  );

  // Dividers between adjacent cavities, plus the outer walls.
  const dividers = Math.max(0, s.cavities.length - 1);
  const required =
    totalCavityWidth + dividers * s.wallThicknessMm + s.wallThicknessMm * 2;

  if (required > s.envelope.widthMm) {
    errors.push(
      `interior needs ${required}mm but envelope is ${s.envelope.widthMm}mm`
    );
  }

  // Every cavity must have a distinct position or they overlap.
  const positions = s.cavities.map((c) => c.position);
  if (new Set(positions).size !== positions.length) {
    errors.push('two cavities share the same position');
  }

  return errors;
}

Run it against a real spec and it tells you the case is 8mm too narrow — before anyone cuts a die.

Why the error message matters more than the check

The valuable part is not the boolean. It is the message:

interior needs 268mm but envelope is 260mm

That single line is what turns a two-week email thread into a five-minute fix. A validator that returns false is useless in a supply chain; a validator that returns the missing millimetres gets acted on.

The general pattern, again

Across all three articles the same shape keeps appearing:

Keep the shared fields shared: envelope, wall thickness, tolerance, finish, quantity.
Push the variable part into a list: profiles for curved products, cavities for multi-item sets.
Validate the additive constraint, and return the number, not the boolean.

A packaging spec is not a form. It is a small constraint problem wearing a form's clothes.

The case shown is a double-opening leather champagne case from TANCYBOX — one bottle, two flutes, three cavities, one envelope.

When a Product Isn't a Box: Modeling Curved Packaging as Data

TANCYBOX — Sat, 17 Oct 2026 08:39:45 +0000

Last time I wrote about modeling a custom physical product as a JSON spec. Everything in that schema quietly assumed a rectangular object: width, height, depth, a tolerance, and corners.

Then a real product arrived that broke all of it — an egg-shaped wine case. No corners, no flat faces, and no obvious "width".

Here's what a curved product exposes about a data model, and how to handle it.

Where the rectangular assumption breaks

The original type was:

type Dimensions = { widthMm: number; heightMm: number; depthMm: number };

For a box, that is complete. For an oval case:

width/height/depth still describe the bounding envelope, but not the form
the front is a curved surface with a cut-out aperture
the interior is profiled to the bottle's shoulder, not a rectangle
tolerance applies to a curve, not to an edge

The moment you need to quote tooling for this, the schema is visibly under-specified.

The fix: separate envelope from profile

Keep the bounding box — it is still useful for volume and shipping — and add a profile describing the actual cross-section:

type Profile =
  | { kind: 'rect'; cornerRadiusMm?: number }
  | { kind: 'ellipse'; rxMm: number; ryMm: number }
  | { kind: 'bezier'; controlPoints: readonly [number, number][] };

type Dimensions = {
  envelope: { widthMm: number; heightMm: number; depthMm: number };
  profile: Profile;
  toleranceMm: number;
};

Now "oval" is data, not a sentence in an email thread.

Three fields a curved case adds

type CurvedCaseExtras = {
  orientation: 'upright' | 'lying';
  aperture?: {
    shape: 'ellipse';
    rxMm: number;
    ryMm: number;
    frameWidthMm: number;
  };
  interiorProfile: 'flat' | 'profiled';
};

Why each one exists:

orientation — a standing oval has an "up" axis. It changes how the case is tooled and how it sits in a shipping carton.
aperture — the window cut into the face. For a plain box this is zero. Here it is a core design element, and it creates a fabrication step of its own.
interiorProfile — the inner cutout follows the product's contour. "Does the bottle fit" stops being a boolean and becomes a curve-fit question.

The general lesson

Physical products do not fit a schema designed for cardboard boxes. The fix is not a bigger schema — it is separating what is universal from what is shape-specific:

Universal: quantity, tolerance, finish, branding, lead time
Shape-specific: envelope + profile + aperture + interior

You get the universal part right once. The shape-specific part you extend per product family, instead of bolting on fields until the model collapses.

Takeaway

If your product data is a width/height/depth triple and nothing else, it works fine — until the first non-rectangular product arrives. Add a profile before that happens, and keep the envelope for everything that genuinely only cares about size.

The curved case in this article is a real product from TANCYBOX, a packaging manufacturer — the schema gaps came from actually having to quote it.

Physical Products Are Data Problems: A JSON Schema for Custom Orders

TANCYBOX — Tue, 13 Oct 2026 08:30:54 +0000

When you order a custom physical product — packaging, furniture, a machined part — the whole transaction is secretly a data problem.

The buyer has a spec in their head. The manufacturer needs that spec in a form where nothing is ambiguous. Every field you didn't define turns into a phone call, a delay, or a remake.

I recently had to model a real product for a quoting workflow: a lacquered wooden wine box. Here's the schema I landed on, why each part exists, and a validator to keep bad specs out.

Why "just send a photo" fails

The default way custom orders happen is unstructured: an email thread, three photos, "about 30cm tall, glossy black", then a revised PDF later.

It fails for predictable reasons:

Ambiguity — "30cm": external or internal? Measured with the lid closed?
Drift — which version of the spec is current?
Missing fields — nobody defines the hinge type until manufacturing starts.
No validation — a spec can't be wrong if it isn't structured.

Structure fixes all four. Once the spec is data, it can be quoted, versioned, validated, and searched.

The schema

The core type, in TypeScript — the shape maps to any language:

type Dimensions = { widthMm: number; heightMm: number; depthMm: number };

type FinishKind =
  | 'raw' | 'matte-lacquer' | 'gloss-lacquer' | 'printed-wrap';

type BrandingMethod =
  | { kind: 'foil'; color: string }
  | { kind: 'emboss' }
  | { kind: 'metal-plaque'; plating: 'gold' | 'silver' | 'rose-gold' };

type CustomProductSpec = {
  product:     { name: string; category: string };
  dimensions:  { external: Dimensions; internal: Dimensions; toleranceMm: number };
  structure:   {
    type: 'rigid' | 'folding' | 'clamshell' | 'drawer';
    wallThicknessMm: number;
    hingeType?: 'none' | 'metal-concealed' | 'metal-exposed';
  };
  materials:   { coreMaterial: string; liningMaterial?: string };
  finish:      { primary: FinishKind };
  branding:    { methods: BrandingMethod[] };
  quantity:    { units: number; sampleRequested: boolean };
};

A few deliberate choices:

External vs internal dimensions are separate fields. Collapsing them into one size is the single most common modeling mistake — they answer different questions (shipping vs fit).
toleranceMm is required. "320mm" without a tolerance is not a specification.
hingeType is conditional. It only means something for a clamshell.
Branding is a list. Real products mix methods — foil and a metal plaque.

A concrete spec

Filling it in for the wine box above (values are illustrative):

const wineBox: CustomProductSpec = {
  product:    { name: 'Glossy Black Wooden Wine Box', category: 'spirits-packaging' },
  dimensions: {
    external:    { widthMm: 320, heightMm: 240, depthMm: 120 },
    internal:    { widthMm: 300, heightMm: 200, depthMm: 100 },
    toleranceMm: 1.5,
  },
  structure:  { type: 'clamshell', wallThicknessMm: 12, hingeType: 'metal-exposed' },
  materials:  { coreMaterial: 'MDF', liningMaterial: 'velvet' },
  finish:     { primary: 'gloss-lacquer' },
  branding:   { methods: [{ kind: 'metal-plaque', plating: 'gold' }] },
  quantity:   { units: 500, sampleRequested: true },
};

Notice what the structured form forces you to decide before production: the lining material, the plating colour, whether a sample is requested. In an email thread, three of those would surface as surprises later.

A validator

Structure without validation is just a nicer-looking mess. The rules that matter:

function validateSpec(s: CustomProductSpec): string[] {
  const errors: string[] = [];
  const { external, internal, toleranceMm } = s.dimensions;

  // Internal must fit inside external.
  if (internal.widthMm >= external.widthMm)
    errors.push('internal width must be smaller than external width');
  if (internal.heightMm >= external.heightMm)
    errors.push('internal height must be smaller than external height');

  // A tolerance of zero is physically impossible.
  if (toleranceMm <= 0)
    errors.push('toleranceMm must be greater than 0');

  // Wall must be positive and structurally sane.
  if (s.structure.wallThicknessMm <= 0)
    errors.push('wallThicknessMm must be greater than 0');

  // A clamshell without a hinge is an incomplete spec.
  if (s.structure.type === 'clamshell' && !s.structure.hingeType)
    errors.push('clamshell requires a hingeType');

  if (s.quantity.units < 1)
    errors.push('quantity must be at least 1');

  return errors;
}

Run validateSpec(wineBox) and you get []. Remove the hingeType and it tells you exactly what's missing — before you order, not after.

Why this generalizes

The same skeleton — dimensions + structure + materials + finish + branding + quantity — describes almost any made-to-order physical product. A garment adds sizeChart; a machined part adds materialGrade and surfaceFinish. The bones don't change.

Once physical specs are data, you get for free:

Instant quoting — a pricing function consumes the spec.
Versioning — specs diff like code.
Validation — catch impossible combinations before tooling.
Search — "every clamshell box we've made with velvet lining."

Takeaways

A custom order is a data problem wearing a supply-chain costume.
Split external and internal dimensions; add a tolerance.
Make conditional fields conditional, and validate what you can.

If you've modeled a physical product's spec before, I'd be curious how your schema differs — the domain-specific fields are usually the interesting part.

The field set above was shaped by modeling real custom orders from TANCYBOX, a packaging manufacturer — the fields buyers most often forget are the ones that cause rework.