Presence
Absence is information. In most ML pipelines a missing value silently becomes a zero, a mean, or an imputed guess — and the model can no longer tell "the sensor read 0" from "the sensor was offline". Tessera never zero-fills: every contracted feature attribute of every event resolves to exactly one of five presence states, and the model sees explicit presence tokens.
The five states
| State | Meaning | What the model sees |
|---|---|---|
present | A parseable value of the declared type | the encoded value token |
missing | Key absent, or an explicit null | the presence token missing |
unknown | A sentinel string: "", "null", "n/a", "none", "unknown" (configurable per project) | the presence token unknown |
corrupted | Present but unparseable as the declared type | the presence token corrupted |
not_applicable | The attribute is not in this event type's contract section | nothing |
The last row is the subtle one: not_applicable is never materialized as a
token. A delay_hours attribute simply does not exist on a
shipment.created event — emitting even a "missing" token for it would
teach the model to count event-type shapes instead of reading behavior.
This non-materialization is an invariant enforced at four independent
layers (contract resolution, tokenizer, dataset validator, and model input
validation); each raises on violation.
A worked example: logistics shipments
A logistics network streams shipment events. Watch one attribute,
delay_hours, declared as a numeric feature of shipment.delayed:
{
"entity": { "type": "shipment", "id": "s_00042" },
"event_type": "shipment.delayed",
"timestamp": "2025-02-11T03:40:00Z",
"attributes": { "delay_hours": 18, "delay_reason": "weather" }
}
Across four real-world messes, presence resolves like this:
| What arrived | Resolution | Why it matters |
|---|---|---|
"delay_hours": 18 | present → quantile-encoded value | the model reads how bad the delay is relative to the observed distribution |
"delay_hours": null (carrier API sent the field empty) | missing | "delayed, magnitude unreported" is behaviorally different from "18 hours" — and from not being delayed at all |
"delay_hours": "n/a" (a legacy feed writes sentinels) | unknown | sentinel strings are recognized, not parsed as categories |
"delay_hours": "tomorrow" (an upstream bug) | corrupted | the pipeline neither drops the event nor invents a number; the model learns this feed misbehaves |
delay_hours on a shipment.scanned event | not_applicable — no token, ever | scans never carry delay data; the model should not be told anything about it |
A shipment whose history reads created → scanned → scanned → delayed(missing) → delayed(missing) — two delays that never reported a
magnitude — is a genuinely different behavioral object than one with two
quantified 2-hour delays. Presence tokens keep that distinction learnable.
Where presence data comes from
Presence rates are profiled at ingestion and surface in three places: the
contract review (each attribute's missingness: expected | rare | never
drives profiling alerts), the dataset manifest, and the evaluation report's
drift baseline — so serving-time drift monitors can tell you when a feed
that used to be present starts arriving corrupted.
Next: Labels and masking — how outcomes become training signal without leaking.