Fourth pillar · what fasten adds to metrics, logs, and traces

Every observability stack ships three pillars: metrics, logs, and traces. Each answers "what is my system doing." fasten adds a fourth pillar that answers a different question: "what did my system commit to, and can we prove it was not rewritten?" This page is about what fasten adds, what it deliberately is not, and how the four pillars compose.

What each pillar answers, and what it cannot

The one question fasten answers that no other pillar can

"Prove that this row was not altered after it was written."

Every fasten audit row carries prev_hash, hash, and monotonic_seq. A single tampered row breaks the chain deterministically; verify_chain() runs offline against any SDK-emitted database and returns first_break_at. A regulator can reproduce the verification without special tooling. See How the hash chain proves tamper-evidence for the walked example.

Metrics have no per-row identity. Logs are a text stream · nothing prevents editing the file. Traces are spans emitted by services; the span store trusts the service. fasten is the only pillar built around "prove no one rewrote history."

Deliberate non-goals · what fasten is not

• Not an APM. No dashboards for CPU, latency, throughput. Use your metrics stack.
• Not a distributed tracer. No span tree, no waterfall UI. Use your trace vendor.
• Not a log aggregator. Syslog and API access are structured but bounded (ring by default). Use your log stack for full-text warehouse.
• Not a replacement for any observability tool. fasten reads request_id from your existing traces; you do not need to replace anything.

The value is the fourth pillar. If you're picking one tool to run all of observability from, fasten is not that tool. If you need the tamper-evident commitment record the other three cannot produce, fasten sits alongside them.

How the four pillars compose

fasten does not compete with your observability stack; it slots in next to it, sharing the correlation id.

1. An incoming request enters your gateway. Your trace vendor stamps a trace id. fasten's HTTP shim stamps a request_id (or reads the one your gateway already stamps).
2. Downstream services emit metrics + logs + spans as they always have. Where a service commits to durable state (a payment captured, a belief updated), it also calls fasten.emit(...) with the same request_id.
3. At read time, a metric anomaly, a log line, and a trace span are joined to the audit row for the same request by the shared id. The auditor's row is the durable, tamper-evident one; the other three are ambient signal.