held‹ ›model

Agreement, model mask against the held polygon

· IoU

first pass · EdgeTAM · three points · loading

concept pass · SAM 3 · "bracket" · 2 found · 0.882 IoU · computed on the server · 2026-09-09

From model task to accepted label file

Image labelsyour model teamcan specify and accept

Bring the model task and source-image conditions. YPAI scopes the label type, task rules, review method, acceptance requirement and output format as one delivery decision.

You buy image-label files in the agreed output format, reviewed against the acceptance criteria in the project scope.

Send your annotation brief How the batch is accepted →
  1. Model task What must the model decide?
  2. Visible boundary Which geometry preserves it?
  3. Review rule What happens when the case is unclear?
  4. Label file Which agreed output is accepted?

Illustrative annotation specimen. The held marks are the route's own geometry; the mask and the number are read in this tab.

Output grammar Classification · Box · Polygon · Keypoints

What must the label file preserve?

Choose the output by the decision your model has to make. One frame, four choices, and four different things that survive into the file.

  1. 01 · Classification

    One class for the whole frame.

    Nothing about where the part is survives.

    in the file category · one for the whole frame

  2. 02 · Box

    Extent and position survive.

    The machined shape does not.

    in the file bbox · 501, 470, 195, 139

  3. 03 · Polygon

    The cut boundary survives, and the bore is carried as its own region.

    in the file segmentation · 19 points · the bore its own region

  4. 04 · Keypoints

    Named landmarks only.

    Here, the three points of the tool axis. The dotted outline is context for reading them, not part of the label.

    in the file keypoints · 3 · named landmarks

Source frame · 1586 × 992 · Illustrative annotation specimen · 3× display derivative

Edge cases Thin geometry · Low contrast · Occlusion · Interior void

Difficult images need explicit rules

Use your sample to name the cases that could change a label. The guideline then states what counts, when a reviewer steps in and which cases move to adjudication.

  1. Case 01 · Thin geometry

    A hose is not its bounding box.

    Traced as a path that carries its own width. The dashed box the same object would get is mostly belt.

    held hose · a path with its own width · 18 px

    model one point · EdgeTAM · loading

    in the file polyline · width 18

  2. Case 02 · Low contrast

    Dark machined metal against a dark cell.

    The boundary follows the tool silhouette, flange top included, not the specular highlight down the barrel.

    held tool · the silhouette, flange top included

    model one point · EdgeTAM · loading

    in the file mask

  3. Case 03 · Occlusion

    Label what is visible. Record what is hidden.

    The run stops at the block edge. Nothing behind the block is drawn, so the hidden part stays a flag and never a guess.

    held hose · visible run to the block edge · occluded: true

    model one point · EdgeTAM · loading

    in the file occluded: true

  4. Case 04 · Interior void

    The bore belongs to the scene, not to the bracket.

    Carried as its own region so the mask of the part is not quietly filled in.

    held bracket · the cut boundary, the bore its own region

    model one point · EdgeTAM · loading

    in the file category: bore

Acceptance method model mask · held polygon · guideline v1 · v2

How will the batch be accepted?

Agree the acceptance requirement before production. The pilot is where an observed result can be measured against it.

guideline
  1. Thin geometry: Path with width, never a box.
  2. Low contrast: Silhouette, not the highlight.
  3. Occlusion: Visible extent only, hidden run flagged.
  4. interior void: not yet written The bore belongs to the scene, not to the bracket. Carried as its own region so the mask of the part is not quietly filled in.

Agreement, model mask against the held polygon

· IoU

The console's record for this decision · img_0001 · ann_0002

the model

First pass
EdgeTAM · three points · loading
Concept
SAM 3 · "bracket" · 2 found · 0.882 IoU · on the server · 2026-09-09
Confidence
·
Vertices
20 held · bore inside · 0 moved

the reviewer

Who
R-01 · image, polygon
Rubric
v1 · as written
Reason
·
Decision
·
At
the specimen's review
Override
none

This is the record the console keeps. The reviewer sees the asset, the instructions and the evidence, and a pseudonymous participant reference.

your review · the bore

Every item leaves review in one of three states, decided against a requirement that was agreed before production.

  1. Accepted The item meets the requirement agreed in the project scope.
  2. Returned for rework The item goes back with the failing rule named, not a score.
  3. Escalated The rule itself did not decide the case. It is still open, and it moves to adjudication.

Model masks are usually right, so a reviewer accepts the bore with them. That sliver is what the rule is for.

The agreed requirement names Human verification · Dual annotation · Specialist review · Agreement analysis · Sampling · Task-specific quality gates

The agreed requirement names five things.

  1. 01 The annotation type, and the geometry it has to produce. classification · box · polygon · keypoints
  2. 02 The rule for each difficult case your data actually contains. four rules on this frame · small instance floor agreed
  3. 03 The review method that decides an item, and who adjudicates. model mask against held polygon · IoU
  4. 04 The sample the requirement was fixed against before production. one agreed sample, fixed before production
  5. 05 The output format the label files are delivered in. COCO JSON · absolute in 1586 × 992

Which of these applies is a scoping decision for your workload. The first four rows are the cases in the frame above. Small instance is listed with them because a size floor is agreed in scoping even when the sample frame you send does not happen to contain one.

File correspondence COCO JSON · Primary artifact

The label files come first

The scope names the output format and the acceptance criteria for the label files. Everything else in the record is qualified by that scope.

Label record img_0001 · ann_0001

source image
1586 × 992 whole frame
shown region
318, 364 560 × 350
category
1 safety_housing one instance
bbox
501, 470, 195, 139 safety housing
segmentation
17 points visible extent
keypoint 1
501, 482 top left
keypoint 2
694, 479 top right
keypoint 3
615, 609 front bottom
guideline
v1, as written
agreement
·
first pass
segmentation · model (EdgeTAM) · loading
concept pass
SAM 3 · "safety housing" · 2 found · 0.938 IoU · server · 2026-09-09
per item
·

Every coordinate here is absolute in the 1586 × 992 frame, never in the view above. That view begins at 318, 364, so keypoint 1 at 501, 482 sits 183 px right and 118 px down from its top-left corner. The values read off the frame are the values in the file, and that correspondence is the thing being bought. The cable gland crossing the left face sits outside the polygon, so the record carries the visible extent and not an assumed rectangle.

If your review requires them, the same scope can add the relevant specification, reviewer record, acceptance record, manifest, version history or change record.

Image annotation services 12 items · one frame · six outputs

The labels your vision model needs

Choose the output by what your model must decide. YPAI scopes the geometry, the case rules, the review method and the file format together.

bbox · safety housing
polygon · bracket + bore
keypoints · tool axis
class · machine-vision cell
bbox · second bracket
agreement · model against held
polyline · hose, width 18
polygon + keypoints · housing
mask · tool
flag · occluded run
concept · brackets from one word
class · conveyor

  1. Object detection

    Locates each object and keeps its extent for the task the model learns.

    bounding boxesoriented boxes

  2. Polygons and segmentation

    Defines the boundaries and regions the task needs, difficult edges and separate instances included.

    polygonssemantic and instance masks

  3. Keypoints and pose

    Marks named landmarks and the structure that connects them.

    keypointsskeletons

  4. Image classification

    Settles the image-level decision with the classes and taxonomy agreed for the workload.

    classeshierarchical taxonomies

  5. OCR and document layout

    Ground truth for reading text and for the structure of a document.

    OCR ground truthlayout annotation

  6. Quality review

    Checks labels against the requirement and decides the cases that need a person.

    reviewagreement analysisadjudication

Our approach one item · four states

Agree the rules. Calibrate the sample. Deliver the labels.

Label recordimg_0001 · ann_0001

category
1 safety_housing
bbox
501, 470, 195, 139
segmentation
17 points
keypoints
3 · named
review
R-01 · rubric v1 · NONE · accepted
file
COCO JSON

Human QA is applied according to the agreed acceptance and sampling plan. Approved sample transfer follows the initial brief through an agreed channel.

Built and operated by YPAI Specification · Controls · Annotation and review · Evidence · Delivery

The platform behind your annotation project

YPAI operates its own bespoke, GDPR-native data collection and assurance platform. Customer specifications and agreements become executable controls across sourcing, collection, technical validation, consent, human review, rights, dataset assembly and delivery.

  1. Specification Your requirement, ontology and acceptance criteria, as written.
  2. Controls Turned into executable checks on every item.
  3. Annotation and review A model's first pass, then a named reviewer, in the console.
  4. Evidence Each decision bound to reviewer, rubric version, reason code and time.
  5. Delivery Label files and records your team can verify.

YPAI review console · rubric v1 · img_0001 · ann_0001 specimen · this item

the model

First pass
EdgeTAM · one point · loading
Concept
SAM 3 · "safety housing" · 2 found · 0.938 IoU
Confidence
·

the reviewer

Who
R-01 · image, polygon
Rubric
v1 · as written
Reason
NONE
Decision
accepted on agreement

People

Specialist review, with responsibility attached

A senior-led managed operation from Oslo. An internal annotation and QA team holds the reference set and the review; contributors are qualified for the project. Clinician reviewers are contracted for medical modalities.

Network

210,000+contributors50+countries

A 210,000+ contributor network across 50+ countries supports project-specific recruitment.

Tooling

The YPAI review console is the platform core. Around it, the leading annotation platforms are set up for each project as adapters, self-hosted CVAT and Label Studio among them, on YPAI's European annotation servers or inside your perimeter for regulated imagery.

YPAI review consoleCVAT · self-hostedLabel Studio · self-hostedinside your perimeter

Norwegian company, EEA-based processing where required · Data residency, subprocessors and transfer controls defined per project, SCCs available · Standard DPA terms under Article 28, per-contributor consent · 30-day end-of-contract erasure · EU AI Act Article 10 documentation supporting your conformity assessment

Your delivery COCO JSON · Pascal VOC XML · YOLO TXT · custom format agreed in scoping

Files your model team can use and accept

The scope names the annotation schema, the output format and the acceptance criteria. The label file and its record describe the same item.

COCO JSON Primary artifact 

{
  "images": [{ "id": 1, "width": 1586, "height": 992 }],
  "annotations": [{
    "id": 1, "image_id": 1, "category_id": 1,
    "bbox": [501, 470, 195, 139],
    "segmentation": [[501, 482, 511, 477, 571, 472, 629, 470, 689, 473, 694, 479,
      696, 556, 686, 564, 685, 593, 615, 609, 612, 578, 559, 577, 513, 571,
      542, 564, 547, 545, 536, 533, 501, 536]],
    "keypoints": [501, 482, 2, 694, 479, 2, 615, 609, 2],
    "num_keypoints": 3, "iscrowd": 0,
    "ypai": {
      "first_pass": {
        "model": "EdgeTAM",
        "prompt": "one point",
        "ran": "client"
      },
      "concept_pass": {
        "model": "SAM 3",
        "prompt": "safety housing",
        "found": 2,
        "ran": "server",
        "date": "2026-09-09"
      },
      "vertices": {
        "held": 17,
        "moved_by_reviewer": 0
      },
      "review": {
        "reviewer": "R-01",
        "rubric": "v1",
        "reason": "NONE",
        "decision": "accepted",
        "at": "specimen"
      }
    }
  }],
  "categories": [{ "id": 1, "name": "safety_housing",
    "keypoints": ["top_left", "top_right", "front_bottom"] }]
}

The ypai object is the review record carried in the file: which vertices the model drew, which a person moved, and who decided. Your schema can rename it.

YPAIDelivery noteimg_0001 · ann_0001 accepted · R-01

Format
COCO JSON
Frame
1586 × 992
Review
R-01 · rubric v1
Date
2026-09-09
Output
The agreed annotation type, in the frame's absolute coordinates
bbox · 17-point polygon · 3 keypoints
Schema
Your classes, geometry and file format
1 category · safety_housing
Review
The item's decision and the record behind it
accepted · NONE · R-01
Records
Specification, reviewer and acceptance records, manifest, version history and change record, as agreed in the project scope
as agreed in scoping

Also available COCO JSONPascal VOC XMLYOLO TXTCustom output agreed in scoping

Scope to delivery You send a sample · One agreed sample · Label files return

From your brief to accepted files

Tell us the source data status, model task, required annotation type, approximate volume, difficult cases, file format, application domain, target timing and acceptance requirement. If part of the specification is unclear, say so.

Send the brief for one workload. We reply with the questions your specification leaves open, and what a first agreed sample would have to settle before production.

Include the use case, the classes or ontology, the difficult cases and any known acceptance method.

YPAI uses the submitted information to review and respond to the image-annotation brief. Do not include image files, credentials or private storage links. Read the privacy notice.

Use general commercial contact

FAQ

Frequently asked questions

What image annotation tasks does YPAI deliver?

YPAI delivers 2D bounding boxes, oriented (rotated) boxes, polygon and instance segmentation, semantic segmentation, keypoint and skeleton annotation, image classification with hierarchical taxonomies, OCR ground truth, and document layout markup. Specialised verticals (medical imaging on DICOM, satellite and aerial, robotics bin-picking) ship with reviewer pools recruited for the modality.

Which image formats and storage targets does YPAI support?

Deliveries are shipped in COCO, YOLO, PASCAL VOC, custom JSON, GeoJSON for geospatial, and DICOM-segmented overlays for medical imaging. Storage targets include AWS S3, Azure Blob, GCP, customer-hosted S3-compatible (MinIO, Ceph) and direct-to-VPC drops. Custom format translation is part of the delivery pipeline, not a post-hoc consulting line.

Can YPAI annotate medical imaging (DICOM, NIfTI)?

Yes. Medical imaging is handled by clinician reviewers contracted for the specific modality (radiology, pathology, dermatology). Data is processed inside EU residency under GDPR Article 9 special-category controls. The controls in place for a given engagement are documented in the statement of work.

How does YPAI handle large-scale annotation backlogs?

Capacity scales with reviewer recruitment, not with crowd-marketplace dispatch. For multi-million-image backlogs the engagement runs in staggered waves with continuous IAA monitoring, so quality drift is caught at the batch boundary rather than at delivery. Active-learning loops are common at this scale to keep human attention on the lowest-confidence examples.

What inter-annotator agreement does YPAI report?

Each batch ships with task-appropriate IAA: Cohen kappa on classification, IoU and mAP on bounding boxes, Dice on segmentation, OKS on keypoints. Targets are set in the SOW per task and per class; underperforming classes trigger re-calibration before bulk progress continues. The IAA report is part of the deliverable, not an audit-only artefact.

Does YPAI provide active-learning or model-in-the-loop image annotation?

Yes. Where the customer has a working baseline model that can be queried EU-locally, YPAI runs human review over model pre-predictions and prioritises low-confidence or high-impact slices. The loop feeds into retraining batches. Hosting patterns (synchronous API, asynchronous batch queue, customer-on-prem) are confirmed during scoping.

Can YPAI annotate inside our perimeter for sensitive imagery?

Yes. For regulated healthcare, public-sector, and critical-infrastructure engagements where third-party processors are not acceptable, the annotation tooling and reviewer access can run inside the customer perimeter (EU regional cloud, on-prem rack, customer VPN). Specific feasibility is confirmed in the scoping document and the controls are written into the DPA.