DIIICE

DIIICE is the six-way taxonomy every DOT is classified into: Data, Intelligence, Instructions, Ideas, Context, and Examples.

DIIICE is the universal taxonomy Dots uses to classify knowledge. It answers one question the same way in every Dotabase: what kind of knowledge is this? The six values are fixed platform-wide. The same list is pinned three times over — in the shared type the application code imports, in the database constraint that guards the column, and in the authoring contract this documentation site itself is written against — so the six values cannot diverge between one surface and another.

The Six Types

  • Data — facts and records: the raw values, entries, and measurements you keep.
  • Intelligence — analysis and understanding: what the data means, synthesized.
  • Instructions — how to do something: procedures, steps, and playbooks.
  • Ideas — proposals and possibilities: what you might do, not yet decided.
  • Context — background and framing: who, where, and under what circumstances.
  • Examples — concrete instances: samples and cases that show rather than tell.

The letters of DIIICE spell the six in order — Data, Intelligence, Instructions, Ideas, Context, Examples — and that order is the one the platform sorts and renders them in. Each of the six also owns its own colour family in the design tokens, so a type looks the same whether you meet it as a chip on a row, a wedge in a chart, or a node in the graph.

Enabling DIIICE Per Dotabase

DIIICE is a per- setting, not a global switch. A Dotabase you create through the app or the CLI has it on unless you ask for it off, and you can change it later. Turning it off changes behavior rather than display: while it is off, rows in that Dotabase carry no DIIICE type at all, and an attempt to set one is refused outright instead of being quietly dropped. Some of the Dotabases seeded into a new workspace ship with it off on purpose, because classifying a bulk import row by row costs an AI call each time.

Where A Type Comes From

Where DIIICE is on, a does the classifying. It runs when a row is created, and again when an update changes the title or the body — editing some other property does not re-run it. This is an AI classification rather than a keyword rule: the behavior hands the row's text to a model and reads back a type, an optional subtype, and a confidence between zero and one. All three are stored on the row, so a low confidence is visible rather than hidden.

You can also set the type by hand. Row create and update both accept a DIIICE type and subtype from the API, the CLI, and the app. A write path that wants its authored value to stand can suppress the classifier for that write, which is exactly what this documentation site does — the type declared in each page's frontmatter is the type the published row keeps.

What The Type Is Good For

The type is a query dimension, not only a label. You can filter on it, group by it, and get result counts broken down by it; it is one of the keys the graph view will cluster on; and search accepts it as a filter from both the CLI and the agent tool surface.

Edge discovery reads it as well. When the platform draws an between two similar rows, the pair of DIIICE types helps decide which kind of edge to draw — an Examples row beside an Instructions row is drawn as one exemplifying the other, and a Data row beside an Intelligence row as one supporting the other.

Where To Go Next

DIIICE · This page in the graph

Connected Records40

Documented by
Mentions
DOT
References
Relevant to
40 connections.

Where To Go Next

Reading this as an agent?For Agents
Something wrong on this page?Dots On GitHub