Privacy

Pulse asks for access to real engineering systems, so it owes you a precise account of what it reads, what it keeps, and what it can never do. This page is that account, and it also covers authentication — because who you are to Pulse determines what Pulse can see.

Pulse reads metadata about execution: that a commit exists, that a pipeline reported a deployment, that a release was tagged. It does not read, store, or transmit your source code. The verification engine needs to confirm that an event happened — it does not need to know what your code says, and we deliberately built it so that it never has the opportunity to find out.

Privacy exists in Pulse so that the record can be honest without being invasive. An engineering record is only useful if people are willing to put real work into it, and nobody puts real work into a system that leaks. The whole design proceeds from the position that provability and disclosure are different things — and that Pulse should demand the first while conceding almost everything on the second.

The most consequential privacy decision in Pulse is not about data at all. It is about who the account belongs to.

In an employer-provisioned model, the company creates your identity, holds it, and destroys it when you leave — taking the record of your work with it. Every privacy guarantee downstream of that is worthless, because the entity you most need protection from is the one holding the account. So Pulse inverts it. Your identity is yours. Organizations attach to it through a membership edge, and when that edge closes, they leave with nothing of yours. An organization cannot delete your events, revoke your proofs, reduce your Build Cred, or take your handle. There is no role, plan or permission that grants any of those, because the capability does not exist in the model.

Authentication in Pulse answers one question: is this the engineer whose work we are about to record? It runs in two places, with two mechanisms, and they are separate on purpose.

• In the browser, you continue with GitHub. There is no Pulse password to be phished, reused, or leaked, and no separate credential to rotate.
• On a machine, pulse login authenticates the machine, not a session. It prints a code, opens a browser, and waits for you to confirm the code matches. The CLI never sees your GitHub credentials, and you never paste a hand-generated token.
• In CI, PULSE_TOKEN authenticates the pipeline, because no browser exists there. It is a credential and belongs in a secret store.
• Machine credentials are independent. Each machine can be revoked on its own without touching the others or your account.

Every event carries a visibility, chosen when it is recorded and defaulted from pulse.json.

1. You authorize GitHub and explicitly select which repositories Pulse may verify against. Nothing outside that list is ever read.
2. The verification engine reads only execution metadata from those sources.
3. Events are recorded with a visibility. The raw record is stored once, in full.
4. Reads are served from projections, which apply visibility and masking per viewer. The stored record is never altered.
5. Reputation is computed from the raw record — so masking what a viewer sees never changes what you earned.

1. Select repositories deliberately during onboarding. Add more later if you need to; nothing is implicit.
2. Set defaults.visibility in pulse.json to match the project — masked for internal work, public for open source.
3. Use PULSE_TOKEN in CI and a browser login on machines you physically hold.
4. Revoke a machine credential the moment you lose the machine.

# Internal project: provable, not disclosed
pulse config set defaults.visibility masked

# Revoke this machine's credential
pulse login --logout

# Confirm who a machine is authenticated as
pulse login --status

• Select only the repositories you actually want recorded. A narrow grant is a smaller thing to reason about.
• Default internal projects to masked rather than private — you keep the same secrecy and lose none of the provability.
• Keep PULSE_TOKEN in a secret store. Never in pulse.json, never in a committed env file, never echoed in a log.
• Revoke machine credentials when a machine leaves your hands, not when you next remember.
• Read the visibility flag before recording an incident on a sensitive system, not after.

• Assuming a private event does not count. It counts in full, and it is verified in full.
• Marking all internal work private, then being unable to prove to anyone outside the company that the team ships. That is what masked is for.
• Believing an employer can erase your record. It cannot. The capability does not exist in the model.
• Committing a credential. pulse.json is safe to commit; ~/.pulse/credentials.json and PULSE_TOKEN never are.
• Disconnecting GitHub expecting it to delete your account. It stops future verification from that source and nothing else.

• Pulse never reads source code. Verification needs to know that a commit exists and who authored it, not what it contains.
• Proofs are tamper-evident, not confidential. Anyone can check that an event matches its evidence hash — that is what makes it a proof.
• You can be authenticated on many machines at once. Each credential is independent and independently revocable.
• Deleting your Pulse account removes your identity and your projections. It does not silently rewrite the timelines of projects other people worked on with you.