Partial Show Representation and Solver API Design

Due: Wednesday (in-class presentations)

moodle

Overview

We now have a working visualizer and a basic show format. However, our current YAML structure is designed around completed wall arrangements, not around building a show algorithmically.

For this next phase, we need to support a more powerful idea:

A “partial show” that a curator defines, which an algorithm then completes.

The curator should be able to specify “must haves” and constraints, and your Python solver should fill in the rest. In the future, we also want this process to be interactive (e.g., solving one wall at a time with curator feedback).

This assignment asks you to design:

1) A revised show file format that supports partial specification
2) An API between the gallery planner and the Python solver

You will work in groups and present your design in class.

Key Design Idea

The most important shift is this:

We must separate:

  • curator intent (what must or should happen)
  • constraints (rules the solver must respect)
  • current accepted placements (what is already fixed)
  • solver proposals (what the algorithm suggests)

Our current format mixes these together inside “arrangements.” Your design should cleanly separate them.

A Proposed YAML Structure (Starting Point)

Below is a proposed structure for a next-generation show file. You should NOT treat this as final. Your job is to evaluate it, critique it, and improve it.

schema_version: "3.0"

show:
  id: "show_01"
  title: "Sample Gund Show"
  gallery_id: "gund_second_floor"
  scoring_profile_id: "vienna_balanced_curatorial_v1"

intent:
  include_artworks:
    - "A1"
    - "Kenyon-Angels"

  exclude_artworks:
    - "A25"

  preferred_themes:
    - "landscape"
    - "photography"

constraints:
  placements:
    - artwork_id: "A1"
      must_be_in_room: "R2"

    - artwork_id: "Kenyon-Angels"
      must_be_on_wall: "R6-W"

    - artwork_id: "A8"
      must_be_near:
        artwork_id: "A5"
        max_distance_ft: 5

  wall_constraints:
    - wall_id: "R7-S"
      required_tags: ["photography"]
      min_items: 4

    - wall_id: "R1-W"
      max_items: 5

fixed_placements:
  - artwork_id: "A1"
    wall_id: "R2-N"
    x_ft: 1.0
    y_ft: 4.5

partial_placements:
  - artwork_id: "A5"
    wall_id: "R2-N"

  - artwork_id: "A8"
    room_id: "R2"

open_spaces:
  - wall_id: "R2-N"
  - wall_id: "R7-S"
  - room_id: "R6"

solver_output:
  status: "incomplete"

  placements:
    - artwork_id: "A5"
      wall_id: "R2-N"
      x_ft: 3.5
      y_ft: 4.5
      source: "solver"

    - artwork_id: "A8"
      wall_id: "R2-N"
      x_ft: 7.0
      y_ft: 4.5
      source: "solver"

diagnostics:
  score: 82.5

  warnings:
    - "Wall R2-N is slightly overcrowded"

  unmet_constraints:
    - "A8 not placed near A5 within desired distance"

Design Questions

Your group should think carefully about the following:

Structure and Representation

  • Is this separation (intent / constraints / placements / solver output) a good idea?
  • Is anything missing?
  • Is anything unnecessarily complicated?
  • Should “partial placements” exist, or should everything be expressed as constraints instead?
  • Should solver output be stored in the same file, or returned separately?

Constraints

  • How should we represent:
  • required artworks?
  • forbidden artworks?
  • placement rules (room, wall, position)?
  • relationships (e.g., “near”, “same wall”, “same room”)?
  • How strict should constraints be?
  • hard constraints (must satisfy)
  • soft constraints (preferences with scoring)

Solver API

Design how the system communicates with the Python solver.

At minimum, describe:

Input to solver:

  • What data structure is passed in?
  • Does it include the full show file or only a subset?
  • How are fixed vs flexible elements identified?

Output from solver:

  • Full completed show?
  • Only new placements?
  • Scores and diagnostics?
  • Multiple candidate solutions?

Interactive Workflow

We eventually want something like:

  • System generates one wall
  • Curator reviews it
  • Curator accepts / rejects / gives feedback
  • System revises or moves on

So consider:

  • How would your design support solving one wall at a time?
  • How would feedback be represented?
  • How would a “rejected” wall be communicated back to the solver?
  • Should the solver be stateless or stateful?

Deliverable for Wednesday

Each group should present:

  1. Your proposed show-file structure
  2. Your proposed solver API
  3. What you changed from the example above and why
  4. How your design supports future interactive workflows

You do not need to implement anything yet.

What This Assignment Is Really About

You are not just designing a file format.

You are designing a contract between human intent and algorithmic decision-making.

The central challenge is not placement.

The real challenge is representing:

  • what is fixed vs flexible
  • what is required vs preferred
  • what the algorithm is allowed to change
  • and how human judgment and algorithmic reasoning interact

The strongest designs will make these distinctions clear, explicit, and enforceable.

Scroll to Top