FAQ

Three things in one place: the questions we are asked most, a troubleshooting guide for when the record is not showing what you expect, and a glossary that defines every term in the product exactly once.

Most questions about Pulse come from one of two places. Either the model is not yet obvious — why can't I log a PUSH, why is my event L1 — in which case the answer is usually a design decision worth understanding. Or something is not being captured, in which case the answer is almost always pulse status.

This page exists so you can stop reading and get back to work. It is deliberately blunt: the answers below state the position rather than softening it, because the surprising parts of Pulse are surprising on purpose.

A recurring theme in these answers is 'no, and it will not be added'. That is not stubbornness. Pulse is a system whose value is entirely derived from the fact that its record cannot be manipulated — the moment events can be edited, PUSHes can be typed by hand, or scores can be set, every other record on the platform becomes worth less. The constraints are the product. They are the reason a Pulse timeline is evidence rather than a claim.

• What is Pulse? An engineering execution platform. It preserves the record of how software was actually built — the events, decisions, incidents and deployments that code alone never explains.
• Is it a replacement for GitHub, Jira or a CI system? No, and it is not trying to be. It does not host code, track tickets or run builds. It records the engineering that happens in the tools you already use.
• Do I have to change how I work? No. Ship as you always have. Execution is captured automatically; the only thing you author is judgment — a BLOCK, an UNLOCK, a PIVOT.
• Why can't I record a PUSH by hand? Because a hand-written PUSH is a self-report, and self-reports are exactly what Pulse exists to replace. Execution is captured from a source or it is not captured.
• Can I edit or delete an event? No. The log is append-only. A correction is a new event, and both remain visible — which is the property that makes the whole record trustworthy.
• Can my employer delete my record or lower my Build Cred? No. Identity is rooted in the developer; organizations attach through a membership edge. No role or permission in Pulse grants that capability, because it does not exist in the model.
• Does Pulse read my source code? No. It reads execution metadata — that a commit exists, that a pipeline reported a deployment. Never file contents, never diffs.
• Can I use Pulse for private or company work? Yes, and this is what the Privacy Mask is for: provable but not leaked. Masked events are verified in full and earn in full.
• Do private events count toward Build Cred? Yes, in full. The engine reads the raw record; masking governs what a viewer sees, not what you earned.
• How is Build Cred calculated? It is derived from verified events, weighted by trust level, across five dimensions — Delivery, Reliability, Resolution, Architecture, Collaboration. Every point traces back to the event that produced it.
• Can I raise my Build Cred faster? Only by doing verifiable engineering. There is no write path, no appeal, and volume is not weighted — ten unverified events can be worth less than one proven one.
• Is the CLI required? Not strictly. BLOCK, UNLOCK and PIVOT can be authored in the Engineering Workspace. Automatic capture and deployment metadata do require it.
• Is there an API? Not yet. It is designed and reserved. Use the CLI — pulse logs --json returns the same projections the API will serve.
• What happens if I leave my company? The membership edge closes. Your events, proofs and Build Cred are untouched, because they were never inside the organization to begin with.

Two commands answer most of what you will want to know, and they answer it from the record rather than from memory.

# What is Pulse capturing right now, and at what trust level?
pulse status --verbose

# What has actually been recorded?
pulse logs --since 30d

Almost every problem with Pulse is one of three things: the machine is not authenticated, the project is not linked, or the event was recorded somewhere other than where you think. pulse status answers all three, and it is the right first move every time.

Run pulse status. It will tell you which of the following is true, in order of likelihood.

This is usually correct behavior rather than a fault. Verification is applied at capture time, against the sources available at that moment.

Every term Pulse uses, defined once. These names do not change between pages, and there are no synonyms — if a concept has a name here, it has that name everywhere in the product.

1. Something looks wrong. Run pulse status.
2. It tells you whether the machine is authenticated, the project resolved, and the repository linked.
3. Fix whichever of the three is not true. That is nearly always the whole problem.
4. Run pulse logs to confirm the record now says what you expect.

A deployment did not appear. Two commands, start to finish.

pulse status

# Project       atlas-gateway (northwind)
# Repository    —                          ✗ not linked
# Identity      @aria                      ✓ authenticated
#
# 0 events captured

pulse link github.com/northwind/atlas-gateway
# ✓ Linked. Verification source: github

• Run pulse status before asking anyone anything. It is faster and it is more accurate.
• Learn the trust ladder. Most 'verification is broken' reports are a correct L1 on an event no machine could ever confirm.
• Use the glossary terms exactly. A shared vocabulary is what makes a record readable by someone who was not there.
• Read the design answers rather than working around them. The constraints are load-bearing.

• Waiting for a feature that will not exist — an edit button, a delete, a manual PUSH, a score override.
• Assuming an event is missing when it was recorded against a different project. Check pulse config list.
• Treating L1 as a failure. It is the honest level for a decision, and decisions are worth recording.
• Reading the FAQ instead of pulse status when something is not being captured. The record knows; this page is guessing.

• Press ⌘K anywhere in the docs to search.
• Every term in the glossary means the same thing on every page. There are no synonyms in Pulse, on purpose.
• If a question is not answered here, it is answered in the page for the concept it concerns. Start with Engineering Events; almost everything follows from it.