Typed layers
Project → Settings → Typed layers.
Where a project defines its typed feature layers: named schemas
of typed attributes (string, boolean, integer, float, link, or a
concept picked from a Knowledge base) that annotators fill in on top
of a span, relation, chain, or the whole document. The tab defines
the schema only; the <TypedFeature>
tag in the labeling config renders it as a form.
Visible to Owner, Admin, Manager, the project creator, and platform staff (the Settings area is manager-gated). The underlying endpoints are scoped to the caller's active organisation — a project in another org is a 404 even for a member of both.
Every edit on this tab saves immediately — there is no page-level Save button.
Layers
+ New layer opens the layer form.
| Field | Effect |
|---|---|
| Name | Required, unique within the project. Shown in the annotation form header and used as the layer's identity. |
| Kind | span (attach to text spans / labels), relation (between two spans), chain (coreference / grouping), or document (document-level). |
| Description | Optional, shown under the layer name on this tab. |
Each layer card shows a layer=<id> chip. That numeric ID is what
the labeling config's <TypedFeature layer="…"> attribute points at.
- Edit layer — change name, kind, description. The ID does not change, so tags keep working.
- Delete layer — removes the layer and all its features after confirmation. Tags that reference the deleted ID fail to load their schema (Layer not found) when a task opens.
Features
+ Add feature on a layer card opens the feature form. Features
are listed in display_order, then name; paginated (10 per page by
default).
| Field | Effect |
|---|---|
| Feature name | Required, unique within the layer. Becomes the key in the stored result (value.typedfeature.<name>). |
| Type | string, boolean, integer, float, link (URL), or Concept, pick from Knowledge Base (concept_kb_ref). Determines the control the annotator sees — text input, checkbox, number, URL, or KB autocomplete. |
| Knowledge Base | Only for concept_kb_ref. Required — the server rejects a concept feature without a KB, and rejects a KB pointer on any other type. The list shows each KB with its entry count. If the org has no KBs yet, create one first (Knowledge bases). |
| Required | Marks the feature as required in the annotation form. |
| Default | Shown for every type except concept. Stored on the feature; the annotation form does not pre-fill from it. |
| Description | Optional help text, shown in the feature table. |
- Edit / Delete per row. Deleting a feature asks for confirmation; existing annotations that already stored a value under that name keep it — the form simply stops rendering the field.
How the annotation side uses this
When a task opens, <TypedFeature layer="N"> fetches layer N's
schema for the current project and renders one control per feature.
A concept_kb_ref feature searches the linked KB's entries (label,
aliases, external ID) and stores the chosen {external_id, label};
every other type stores its native JSON scalar.
- A tag without a
layerattribute shows a misconfiguration error. - A layer with no features shows a has no features yet hint instead of a form.
See <TypedFeature> for
the tag attributes and result payload, and
<KBRef> for standalone concept
linking without a layer.
Relation to Knowledge bases
Knowledge bases are org-level (Organization → Resources → Knowledge bases) and shared across the org's projects; typed layers are per-project. A concept feature is the bridge: it points at one KB, and that KB's entries feed the autocomplete for that one feature. Deleting a KB leaves concept features that pointed at it with no KB (the pointer is nulled, the feature stays).
Gotchas
- Layer and feature names are unique per project / per layer — a duplicate name is rejected on save.
- The layer ID is per project. Saving a project as a template copies
the labeling config but not the typed layers, so a
<TypedFeature layer="7">in a template points at nothing in the new project until you recreate the layer and update the ID. - Layers, features, and KBs are resolved against your active organisation. If you're switched into a different org than the project's, the tab and the annotation form cannot load them.
What's next
<TypedFeature>→ — the control tag, its attributes, and the stored payload- Knowledge bases → — creating KBs and importing entries
<KBRef>→ — concept linking on a region without a typed layer- The three-layer stack → — where typed layers sit in the platform