Validate a two-portrait video plan without inventing a price quote

Carl Sagen — Thu, 15 Oct 2026 13:06:45 +0000

Disclosure: This is an AI-generated educational article and original code example, prepared for an authorized ClipRoam distribution task. It does not upload portraits, call the product API, or claim a completed paid-generation test.

A short AI-video form mixes two different decisions: what the user wants to create, and whether the user wants to pay the actual quoted cost. A client-side checklist can help with the first decision without pretending to answer the second.

Consider a scene with two portraits. “Make them interact” leaves several things unspecified: which person takes which role, what action should happen, and whether the duration leaves room for it. Explicit fields make those omissions visible before an upload or generation request.

Keep the planner independent of billing

This pure function validates a small plan. It uses no network requests and stores no data. The allowed durations and qualities are illustrative UI options, not a substitute for a service's current capabilities.

export function validateVideoPlan(input = {}) {
  const plan = input ?? {};
  const text = value => typeof value === "string" ? value.trim() : "";
  const issues = [];

  if (!text(plan.leftRole)) issues.push("Define portrait 1's role.");
  if (!text(plan.rightRole)) issues.push("Define portrait 2's role.");
  if (!text(plan.action)) issues.push("Describe one visible action.");

  if (![5, 10].includes(plan.duration)) {
    issues.push("Choose a supported duration.");
  }
  if (!["720P", "1080P"].includes(plan.quality)) {
    issues.push("Choose a supported quality.");
  }
  if (plan.hasPortraitPermission !== true) {
    issues.push("Confirm permission before uploading portraits.");
  }
  if (plan.willReviewQuote !== true) {
    issues.push("Review the actual quote before generation.");
  }

  return { readyForReview: issues.length === 0, issues };
}

The return value deliberately says readyForReview. A valid object is neither proof of consent nor authorization to spend credits. In a production app, the server must still authenticate the relevant action, validate the upload and settings, obtain an authoritative quote, and require the appropriate confirmation before creating a paid job.

Notice that the two checkbox values require the boolean true. Strings such as "false" and "true" are both truthy in JavaScript, so a generic truthiness check would hide a common form-integration mistake. Likewise, the example expects numeric durations: normalize your UI input deliberately rather than silently accepting arbitrary strings.

Two small examples

validateVideoPlan({});
// readyForReview: false, with seven actionable issues

validateVideoPlan({
  leftRole: "human partner",
  rightRole: "fictional zombie partner",
  action: "They turn toward each other and share a gentle hug.",
  duration: 5,
  quality: "1080P",
  hasPortraitPermission: true,
  willReviewQuote: true
});
// { readyForReview: true, issues: [] }

An empty plan should produce useful next actions. A complete plan should preserve the two role assignments. It should not infer a price from the duration or turn the checkbox into a claim that the service has verified the user's rights.

Give validation a clear place in the interface

Render the issues as text beside the form, and use an aria-live="polite" status region for the resulting summary. Preserve the entered values when a check fails. If the user changes a setting after receiving a quote, treat the old quote as belonging to the old settings; obtain a fresh one before confirming generation.

The product context for this example is ClipRoam's public two-portrait workflow. It offers a studio duet or gentle zombie reunion, five- or ten-second landscape videos, and 720P or 1080P output. Uploads and quotes are free, while generation uses one-time paid credit packs starting at USD 8. The public site describes a three-day window for video downloads.

That download window belongs in the post-generation experience, alongside the real job status and download action. It does not belong in a planner as a fabricated expiry timestamp: the example has not created a job and therefore has no download deadline to calculate.

The useful boundary is concrete: the planner improves an incomplete request; the service provides the actual quote and job state. Keeping those responsibilities separate makes both the UI and its claims easier to inspect.

Specify interactive explanations as inputs, state and checks

Carl Sagen — Sun, 11 Oct 2026 15:31:12 +0000

An interactive explanation needs a small behavioral specification. Naming the inputs, the state and a few checks gives a developer something more precise to build or review than a request for an attractive interface.

This article was generated with AI assistance and source verification. The code below is an original, deterministic example. It does not claim that a particular ChatGPT account produced or supports a particular interface.

Start with one task

Consider a study planner that offers 25, 45 or 90 minutes. Its job is to divide the chosen time into warmup, practice and recall, while keeping completion marks separate from the time allocation. The independent Intelligent UI field guide provides prompt ideas and an original browser demo as reference points. Its own demo is labelled as a site demo, rather than a verified ChatGPT output.

For an original example, keep warmup at five minutes and recall at ten. Practice gets the remaining minutes. These are design choices for this example, not an experimentally established learning schedule.

export function allocate(minutes) {
  if (![25, 45, 90].includes(minutes)) {
    throw new RangeError('Choose 25, 45 or 90 minutes.');
  }
  return { warmup: 5, practice: minutes - 15, recall: 10 };
}

Separate input state from completion state

The selected duration determines the allocation. A checked task records an action by the user. Checking a box should not silently change the duration or claim that the topic has been learned. Resetting completion marks should not erase the selected duration unless the reset action says it does.

Keeping those relationships explicit makes a generated interface easier to evaluate. A slider, radio group or select box can represent the same input; the behavior matters before the visual treatment.

Check totals, boundaries and rejected inputs

For each permitted duration, all three blocks must be nonnegative and their sum must equal the selected duration. Check the smallest and largest values, then an unsupported value. Do not silently accept 40 minutes when the specification offers only three choices.

for (const minutes of [25, 45, 90]) {
  const plan = allocate(minutes);
  const total = Object.values(plan).reduce((sum, value) => sum + value, 0);
  if (total !== minutes) throw new Error('Incorrect time total');
  if (Object.values(plan).some(value => value < 0)) {
    throw new Error('Negative time block');
  }
}

These checks verify this allocation function. They do not test an entire browser interface, a model response or the learning outcome of the schedule. Add separate checks for labels, controls, completion marks and reset behavior when implementing an actual interface.

State the expected feedback in the prompt

An original prompt could ask for a planner that uses only the three durations, explains the allocation formula and shows the total beside the controls. Ask it to keep unknowns explicit and to avoid treating task completion as proof of understanding.

OpenAI's prompt-engineering documentation explains that generated content can vary. Inspect the response you receive against the behavior you specified. An interface sketch is a starting point for that review, rather than evidence that the checks passed.

Published under Carl Sagen's authorization for IntelligentUI. Source information checked October 11, 2026. No account-specific feature availability or firsthand model-output experiment is claimed.

DEV Community: Carl Sagen