Availability

Capture gets the work recorded, but a record no one can question is just storage. Availability is the discipline of organizing that record so anyone can put a question to it and get an answer: how often a tool call fails for a given reason, which sessions touched a service, where the spend is concentrated.

When the trail is queryable, your team answers its own questions instead of routing each one through whoever knows where the logs live. The payoff is a record the org can interrogate directly: finding out how your agents are behaving costs a query, not a wait.

Exploratory

Whatever was captured is a pile, and “how often does this fail?” has no answer yet.

Enables

A raw record exists, and reading it by hand surfaces the questions your org actually puts to it. Those questions are what a queryable schema later gets shaped around.

Deficiencies

Nothing is queryable, no one knows what is in there or where to look, and questions go unanswered.

Cost to maintain

Time spent digging through logs for an answer that may not be there.

Expert-led

One person is the query layer, and the record is only as reachable as they are.

Enables

Real answers to “how often” and “which sessions,” as long as that person is around to pull them.

Deficiencies

A single point of failure whose knowledge of how to query lives in their head, so it does not scale past their calendar.

Cost to maintain

Their time fielding and running queries.

Documented

The team knows where the record lives and how to ask it questions, and the conventions are written down.

Enables

Anyone on the team can answer common questions from the record, and it survives the expert leaving.

Deficiencies

Still manual querying that depends on people keeping the format parseable, with gaps whenever capture changes shape.

Cost to maintain

Writing down the schema and query conventions, plus keeping comments and trackers in the agreed format.

Structural

The record is append-only with a schema, and anyone can run their own query long after the author is gone.

Enables

Questions answered without a person in the loop, consistent and repeatable queries, and a system of record with a memory the org can draw on.

Deficiencies

Schema drift breaks queries when capture changes, and a dashboard can imply an answer the data does not support.

Cost to maintain

Building and versioning the schema and dashboards upfront, plus tuning as capture evolves.

Availability rarely stands alone. Where it overlaps a sibling discipline, an investment on one side quietly depends on the other. The Observability domain page lays these out in full.

• Availability and Trace

  Availability and Trace answer opposite questions of the same record. Availability reads across every run at once while Trace goes vertical on one of them, the full walk of a single case down to the reasoning behind it.

  You need both postures, because a query that flags a spike in failures cannot tell you why any single one broke, and reconstructing that one broken run cannot tell you whether it is a fluke or a pattern. Fund only breadth and you are watching a trend you cannot diagnose; fund only depth and you are explaining a case you cannot place.

• Availability and Capture

  Capture writes the record; Availability decides whether anyone can ever ask it anything. A session logged and then sealed away is the worst line on the bill: you paid for the instrumentation and the storage and bought back nothing, because the answer is technically in there and functionally gone.

  The two only pay off together: capture wide, then make it reachable. Log nothing and there is nothing to ask; log everything into a pit and you have funded a haystack no one will search.