Type Safe
Back to Workflow
WorkflowType Safe WorkflowExperimentalNeeds review

Jev Image and Box Workflow

A display-only workflow for checking whether a visual target exists before Jev 1.14 returns one Box result for review.

This independently maintained guide documents a cautious Jev image workflow with a Noul presence check, one-target Box localization, coordinate validation, and human review. Images and Box are Dreamer-ready experimental features, not production-ready capabilities, and the request shape, answers, and limits may change.

Provider
Type Safe Workflow
Reviewed
October 19, 2026
Project status
Experimental
Verification
Needs review
Categories
automation, development, research
Compatibility
Jev 1.14, Jev 1.13, Experimental Images, TypeSafe API

Inputs

  • ✓PNG or JPEG image
  • ✓One visual target description per Box question
  • ✓Human-review confidence threshold

Outputs

  • ✓Target-presence decision
  • ✓Single bounding box
  • ✓Box confidence
  • ✓Review status and audit metadata

Workflow steps

  1. 1Preflight the PNG or JPEG format, dimensions, file size, and authorization to process the image before creating a request.
  2. 2Create a unique, non-colliding asset reference and keep raw image bytes out of ordinary application logs.
  3. 3Add TypeSafe-Danger-Zone-Images: true and record that the experimental interface may change.
  4. 4Read answers.target_present.noul as a 0 to 1 presence probability and route it with a locally calibrated presence threshold; send ambiguous values to human review.
  5. 5Write one Box question for one target; split multiple targets into separate questions.
  6. 6Read the single bounding box and confidence returned for that target.
  7. 7Validate coordinate order, bounds, numeric values, and the confidence range before downstream use.
  8. 8Send low-confidence results, absent targets, invalid coordinates, and high-impact cases to human review.
  9. 9Record the model ID, danger-zone header, request version, presence result, Box result, confidence, and reviewer outcome for audit.

Decision tasks

  • ✓Extract
  • ✓Verify

Workflow implementation guide

This editorial pattern requires local evaluation before operational use. Empty tested-version fields mean the directory has not run it against a pinned model release.

Business problem

A visual decision workflow needs to locate one target without mistaking a mandatory Box response for proof that the target actually exists.

Who this is for

Teams evaluating experimental visual extraction with an explicit human-review path.

Model selection notes

Jev 1.13 and Jev 1.14 both accept danger-zone experimental images, but the Box primitive requires Jev 1.14. This editorial page is not live-tested, does not call the TypeSafe API, and does not establish production readiness.

Tested model versions

Unknown

Industry
Software, Document processing, Visual quality review
Difficulty
intermediate
Estimated setup time
2 to 4 hours for a documentation-led prototype
Compatible model candidates
jev-1-14, jev
Required integrations
TypeSafe API image input, Jev 1.14 Box primitive, Human review process
Recommended model
jev-1-14

Detailed execution steps

  1. 1Preflight the PNG or JPEG format, dimensions, file size, and authorization to process the image before creating a request.
  2. 2Create a unique, non-colliding asset reference and keep raw image bytes out of ordinary application logs.
  3. 3Add TypeSafe-Danger-Zone-Images: true and record that the experimental interface may change.
  4. 4Read answers.target_present.noul as a 0 to 1 presence probability and route it with a locally calibrated presence threshold; send ambiguous values to human review.
  5. 5Write one Box question for one target; split multiple targets into separate questions.
  6. 6Read the single bounding box and confidence returned for that target.
  7. 7Validate coordinate order, bounds, numeric values, and the confidence range before downstream use.
  8. 8Send low-confidence results, absent targets, invalid coordinates, and high-impact cases to human review.
  9. 9Record the model ID, danger-zone header, request version, presence result, Box result, confidence, and reviewer outcome for audit.

Confidence policy

Treat confidence as a routing signal, never as a correctness guarantee. Calibrate the review threshold on representative labeled images and track false-presence and bad-localization rates separately.

Human review policy

Require review when the Noul presence probability is invalid, below the locally calibrated presence threshold, or in an ambiguous range; also review low Box confidence, invalid coordinates, multiple-target ambiguity, and results affecting safety, access, identity, money, or legal rights.

Privacy notes

Images may contain faces, identity documents, health details, or other sensitive data. Minimize collection, confirm authorization and purpose, restrict access, define a short retention period, and keep raw image content and secrets out of logs.

Cost notes

Official pricing is based on input tokens, and the expanded image representation counts toward request limits. TypeSafe does not publish a stable unit estimate for that expansion, so this guide makes no image-specific cost projection.

Common failure modes

  • ✓Box always returns a box even when the requested target is absent.
  • ✓Confidence is treated as proof that the localization is correct.
  • ✓One Box question describes several targets and produces an ambiguous result.
  • ✓The danger-zone image header is missing or the experimental request contract changes.
  • ✓Coordinates are malformed, out of range, or interpreted in the wrong coordinate system.
  • ✓Sensitive image data is copied into logs or retained without a defined purpose.

Troubleshooting

  • ✓Recheck the current Images and Box documentation before implementing a request because experimental formats and limits may change.
  • ✓Run the presence check independently and never infer presence from the existence of a Box answer.
  • ✓Split multi-target prompts and inspect each target separately.
  • ✓Compare rendered boxes with labeled examples and recalibrate the review threshold.
  • ✓Pause automation and require review when coordinate conventions or answer fields do not match the validated contract.

Structured request example

{
  "model": "jev-1.14.0",
  "state": {
    "image_asset": "jev_box_image_01",
    "review_threshold": 0.85
  },
  "assets": {
    "jev_box_image_01": {
      "type": "image",
      "part": "<multipart part reference omitted>"
    }
  },
  "questions": {
    "target_present": {
      "type": "noul",
      "instructions": "Using the image in state field `image_asset`, is the red warning label visible?"
    },
    "target_box": {
      "type": "box",
      "instructions": "Using the image in state field `image_asset`, locate the red warning label."
    }
  }
}

Pure Box-answer validator with review examples

typescript ·

jev-1.14.0 documentation contract
type ReviewStatus = 'accept' | 'review';

function isRecord(value: unknown): value is Record<string, unknown> {
  return typeof value === 'object' && value !== null;
}

function isUnitNumber(value: unknown): value is number {
  return (
    typeof value === 'number' &&
    Number.isFinite(value) &&
    value >= 0 &&
    value <= 1
  );
}

function validateBoxAnswer(
  presenceProbability: unknown,
  result: unknown,
  reviewThreshold = 0.85,
  presenceThreshold = 0.8
): ReviewStatus {
  if (
    !isUnitNumber(presenceProbability) ||
    !isUnitNumber(reviewThreshold) ||
    !isUnitNumber(presenceThreshold) ||
    presenceProbability < presenceThreshold ||
    !isRecord(result) ||
    !isRecord(result.box)
  ) {
    return 'review';
  }

  const top = result.box.top;
  const bottom = result.box.bottom;
  const left = result.box.left;
  const right = result.box.right;
  const confidence = result.confidence;
  if (
    !isUnitNumber(top) ||
    !isUnitNumber(bottom) ||
    !isUnitNumber(left) ||
    !isUnitNumber(right) ||
    !isUnitNumber(confidence) ||
    !(left < right) ||
    !(top < bottom)
  ) {
    return 'review';
  }
  return confidence >= reviewThreshold ? 'accept' : 'review';
}

const officialShape = {
  box: { top: 0.1, bottom: 0.6, left: 0.2, right: 0.8 },
  confidence: 0.91,
};
const invalidOrder = {
  box: { top: 0.7, bottom: 0.3, left: 0.2, right: 0.8 },
  confidence: 0.91,
};
const nonNumericConfidence = {
  box: { top: 0.1, bottom: 0.6, left: 0.2, right: 0.8 },
  confidence: '0.91',
};

const accepted = validateBoxAnswer(0.95, officialShape, 0.85, 0.8); // 'accept'
const wrongOrder = validateBoxAnswer(0.95, invalidOrder, 0.85, 0.8); // 'review'
const ambiguousPresence = validateBoxAnswer(0.55, officialShape, 0.85, 0.8); // 'review'
const nullResult = validateBoxAnswer(0.95, null, 0.85, 0.8); // 'review'
const missingBox = validateBoxAnswer(0.95, { confidence: 0.91 }, 0.85, 0.8); // 'review'
const invalidConfidence = validateBoxAnswer(0.95, nonNumericConfidence, 0.85, 0.8); // 'review'

Implementation guidance

Keep the declared inputs and outputs visible in code review. Validate every model response before it reaches a database, API, or customer-facing action.

Related resources