Pulse Documentation

Pulse is an engineering execution platform. It records what your team actually did — the deployments, the decisions, the incidents, the fixes — and turns that record into a permanent, verifiable engineering timeline. These docs explain what Pulse is, why it works the way it does, and how to use it.

A repository preserves code. It does not preserve engineering. Six months after a launch, the diff is still there, but the reasoning is gone: why the cache was replaced, what broke at 3am, who worked the incident, what the team learned, which decision was reversed and why. That context lived in a chat thread, a call, a ticket that was closed and archived. It is unrecoverable.

Pulse captures that layer. Every meaningful thing that happens around the code becomes an engineering event: an append-only record with a timestamp, an author, a project, and — where a machine can confirm it — a proof. Events accumulate into a timeline. Timelines connect into a graph. The graph is the engineering record: an honest account of how a system got to where it is, and who did the work.

Pulse exists to make engineering execution durable and provable. Three things follow from that.

• Systems become explainable. Every deployment, incident and architectural reversal is on the timeline, in order, with its reasoning attached.
• Knowledge stops evaporating. An incident that was worked through in the open becomes a knowledge artifact that outlives the people who resolved it.
• Contribution becomes verifiable. Build Cred is derived from confirmed execution, so what an engineer claims to have built can be checked rather than believed.

Engineering is judged on artifacts that are bad evidence. A commit count says nothing about the outage it prevented. A resume claims impact with no way to check it. A postmortem doc is written once and read never. Meanwhile the actual signal — that this engineer took a production incident from detection to resolution in four hours, and the fix has held for a year — is scattered across four systems and belongs to none of them.

We built Pulse on a simple position: execution is the record. Not intent, not the plan, not the self-report. What shipped, what broke, what was decided, what was learned. If that record is captured as it happens, verified where it can be, and never rewritten, it becomes the most useful artifact an engineering team owns — and the most credible thing an engineer can carry between jobs.

Pulse is a small number of concepts that compose. Each has its own guide; this is the shape of the whole.

Pulse sits beside your existing workflow rather than inside it. Nothing about how you write, review or ship code changes.

1. You connect an account and link a repository to a Pulse project.
2. Execution is captured automatically. Pushes, deployments, releases and CLI activity arrive as events without anyone logging them.
3. Context is captured deliberately. When you hit a wall, resolve it, or reverse a decision, you record a BLOCK, an UNLOCK or a PIVOT — the things no machine can infer.
4. The verification engine attests what it can confirm from source, and assigns a trust level to the proof.
5. Verified events roll up into Build Cred, into project and organization timelines, and into the engineering graph.

  SOURCES                 CAPTURE                VERIFY                 DERIVE

  Repository ──┐                                                    ┌── Timeline
  Pipeline   ──┼──▶  Engineering Event  ──▶  Proof (L0–L4)  ──┬──▶ ├── Knowledge
  CLI        ──┘     (append-only log)      tamper-evident    │    ├── Build Cred
                             ▲                                │    └── Engineering Graph
  You ───────────────────────┘                                │
  BLOCK · UNLOCK · PIVOT                                      │
  (judgment a machine cannot infer)                           │
                                                              ▼
                                          Nothing writes back. The log is the only truth;
                                          everything to its right is derived from it.

The split matters, and it is not arbitrary. Machines are good at recording that something shipped; they are useless at recording why. So Pulse captures execution automatically and never asks you to self-report it — and it asks you to author only the judgment: the block you hit, the reasoning behind the fix, the decision you reversed. This is also why a PUSH cannot be created by hand anywhere in the product.

A week on Pulse, for a working engineer, looks like this. Most of it is passive.

1. Ship as usual. Pushes and deployments land on your project timeline on their own.
2. Hit a production problem. Open a BLOCK to record it — the symptom, the impact, the system under it.
3. Work the incident. Others contribute in the BLOCK room; every step stays attached to the record.
4. Resolve it. Record an UNLOCK linked to the BLOCK, with the fix and the evidence behind it.
5. The resolution becomes a knowledge artifact. The next engineer to hit that failure finds your write-up.
6. Verified events raise your Build Cred and your project's record. You never asked for either.

The example used throughout these docs is real in shape: an engineer, @aria, works on atlas-gateway, a request gateway owned by the northwind organization. Here is the whole arc from install to a verified record.

# One-time setup
npm install -g @pulse/cli
pulse login
pulse init --project atlas-gateway --org northwind
pulse link github.com/northwind/atlas-gateway

# From here on, execution captures itself
pulse deploy --environment production --version v2.4.0

# You record only what a machine cannot infer
pulse event block --title "Connection-pool exhaustion under deploy stampede"

• Read the core concepts before the CLI. The commands are trivial; the model is the part worth understanding.
• Link real repositories. Verification is only as strong as its sources — an unlinked project can never rise above a self-attested trust level.
• Record BLOCKs while you are still stuck, not after. A BLOCK written from memory loses exactly the detail that makes it useful later.
• Treat the timeline as the record of truth. If it did not make it onto the timeline, it did not survive.

• Treating Pulse as a status report. It is not a place to describe work you plan to do — it records work that happened.
• Trying to log a PUSH by hand. You cannot, by design. If pushes are not appearing, the repository link is the problem.
• Recording an UNLOCK with no BLOCK. A resolution with nothing to resolve carries no weight and produces no knowledge artifact.
• Expecting Build Cred to move on volume. It is weighted by verification, not by count. Ten unverified events are worth less than one proven one.

• Everything on a timeline is append-only. Events are never edited or deleted — a correction is a new event that supersedes the old one, and both remain visible.
• Visibility and verification are independent. A private or masked event is still fully verified and still counts toward Build Cred; the proof is public even when the detail is not.
• Press ⌘K anywhere in the docs to search.