Documentation / Behavior schema
Six questions define the record.
A behavior is a structured security object. It is not an alert label, an anomaly score or a generated summary. Its six dimensions preserve what acted, what it could do, what it did, what changed and how much of that picture was actually visible.
Dimensions
| Plain-language question | Record concern | Purpose |
|---|---|---|
| Who or what acted? | Execution context | Identifies the process, user, service or system behind activity |
| What can it do? | Functional profile | Describes capabilities relevant to observed behavior |
| What did it do? | Actions | Records the operations actually performed |
| What changed immediately? | Immediate effects | Captures changes produced during execution |
| What remained afterward? | Persistent effects | Captures state that survived the activity |
| How certain are we? | Observability | Separates direct observation, inference and missing telemetry |
Representative shape
The specimen currently used by the site exposes fields in this general shape:
{
"behavior_id": "bhv_8f2c41a9",
"type": "Persistence",
"actor": "powershell.exe",
"host": "FINANCE-WS-042",
"user": "j.smith",
"first_observed": "10:42:18Z",
"effect": "Execution configured for user logon",
"evidence": "6 events / 2 sensors / 1 rule",
"observability": {
"state": "telemetry_gap",
"detail": "no endpoint telemetry 10:42:31 - 10:44:02"
}
}
Specimen boundary: this example is a representation specimen, not an API contract.
Relationships
Behaviors can compose into parent and child activity, share resources, and form sequences. These relationships belong to the representation itself so that downstream consumers do not have to reconstruct them independently.
Next
Read Evidence states before treating any field as equally certain.