Privacy Mask

The Privacy Mask resolves the tension at the center of Pulse: most real engineering happens on systems that cannot be discussed publicly, and an engineer should not have to choose between keeping their employer's secrets and having a record of their work. The mask means they don't have to.

A masked event is fully recorded, fully verified, and fully counted. What changes is what a given viewer is shown: the event's existence, its kind, its timestamp, its proof and its trust level are visible, while the sensitive detail — the description, the system names, the internals — is sealed. Someone reading your profile can see that you resolved a verified L3 production incident on that Tuesday. They cannot see what it was about.

The mask exists so that a decade of serious engineering done inside companies is not invisible. Most of the best engineering work in the world happens on private systems. Without a mask, the only records that can be public are hobby projects and open source — which is exactly the bias that makes hiring and reputation so unreliable today.

The naive implementation is to strip the sensitive fields before storing them. It is also fatally wrong, and the reason is worth sitting with.

If the detail is destroyed at write time, then the event cannot be verified against a source — you deleted the thing the proof would check. Your reputation engine cannot weigh it properly, because it cannot see what happened. Your own audit trail cannot reconstruct it. And a future employer, to whom you might want to disclose it, can never be shown it, because it is gone. Masking at write time protects the secret by destroying the evidence, which defeats the entire purpose of a system built on evidence.

So the mask is applied on read, per viewer, when a projection is built. The raw record is always stored in full and always readable by the engine and by you. Verification reads raw. Reputation reads raw. Audit reads raw. Only the projection served to a given viewer is masked — which means the event is provable and not leaked, at the same time, without contradiction.

• Projection-not-mutation — the raw event is never altered. The mask is applied when a view is built for a viewer.
• Viewer class — what is unsealed depends on who is asking: you, a colleague in the organization, or the public.
• The engine reads raw — verification and Build Cred always read the unmasked record, so masking never costs you a point.
• Organization mask policy — an organization can set a floor. Members cannot disclose below it; they can always choose to disclose less.
• Audit reads raw — the record remains fully reconstructible for the people entitled to reconstruct it.

The mask is what makes a record safe to share, and sharing is the point of having one. Your profile lives at a permanent public address — /@aria — and what a given person sees there is decided by the mask, not by a copy you prepared for them.

• Share your profile, not a resume. It is the same record you use daily, it is verified, and it is current the moment you ship.
• Share an event or a knowledge artifact directly. Each has its own permanent URL, and each carries its proof with it.
• Share a project's timeline as an account of how a system was built — the deployments, the incidents, the reversals, in order.
• A masked item shared publicly stays masked. There is no share mode that quietly unseals it, and no link that leaks it.

1. You record an event with visibility masked, or your organization's policy applies the mask for you.
2. The event is stored in full. Nothing is stripped.
3. The verification engine reads the raw record and mints a proof at the level its source supports.
4. Build Cred is computed from the raw record, weighted by that trust level.
5. When any surface is rendered, the projection layer builds it for that specific viewer, applying the mask.
6. Public viewers see the proof and the shape. The engine, the audit trail and you see everything.

  STORED ONCE, IN FULL                    RENDERED PER VIEWER

  evt_ledger_audit_unlock                 ┌── You
  ├── kind        UNLOCK                  │   everything. always.
  ├── title       "Closed ledger-core…"   │
  ├── description full internal detail ───┼── Your organization
  ├── project     ledger-core             │   everything the policy allows
  ├── proof       L3 · ci_pipeline        │
  └── buildCred   31                      └── The public
            │                                 kind · date · proof · level · 31 points
            │                                 detail SEALED
            │
            ├──▶ Verification engine  reads RAW
            ├──▶ Reputation engine    reads RAW   ── so masking never costs you a point
            └──▶ Audit                reads RAW

  The mask is applied when a view is built, never when the record is written. Destroying the
  detail at write time would destroy the evidence — and evidence is the entire product.

1. Set defaults.visibility to masked on internal projects, once, in pulse.json.
2. Record incidents and decisions exactly as you would in the open. Write the full detail — it is stored, and it is yours.
3. Ship. Deployments on the project are masked by the same default.
4. Share your profile freely. Colleagues see the substance; the public sees the proof.

# Everything on ledger-core is provable, and nothing is disclosed
pulse config set defaults.visibility masked

pulse event unlock \
  --resolves evt_ledger_audit_block \
  --title "Closed ledger-core audit findings with signed proofs" \
  --description "Full internal detail — stored, verified, and never rendered to a public viewer."

{
  "id": "evt_ledger_audit_unlock",
  "kind": "UNLOCK",
  "title": "Resolved a verified incident",
  "project": "Private project",
  "occurred_at": "2026-06-27T08:00:00Z",
  "privacyStatus": "masked",
  "maskedNote": "Detail is sealed. The proof and its trust level are not.",
  "verification": {
    "status": "verified",
    "level": "L3",
    "method": "ci_pipeline",
    "proofId": "proof_1b47f009"
  },
  "buildCredEarned": 31
}

• Prefer masked over private for company work. Both keep the secret; only one lets you prove you did the work.
• Write masked events in full detail. The detail is stored, verified and yours — the mask governs display, not what you are allowed to record.
• Set the mask as a project default rather than remembering it per event. The one you forget is the one that mattered.
• Point people at your profile rather than exporting a summary. A live, verifiable record is the whole product; a screenshot of one is not.

• Believing masked events earn less. They earn identically — the engine reads the raw record.
• Writing a vague description because the event is masked. You have stripped the value from your own record to protect a secret the mask was already protecting.
• Confusing masked with private. Private hides the event's existence. Masked proves its existence while sealing its detail.
• Expecting a share link to unseal something. Nothing about sharing changes what a viewer is entitled to see.
• Assuming an organization can force disclosure. Mask policy is a floor, not a ceiling — it can require more secrecy, never less.

• The mask applies everywhere a record is read: profiles, timelines, feed, search, knowledge and the leaderboard. There is no surface it is not applied to.
• Masked incidents still produce knowledge artifacts. The lesson is publishable even when the system is not.
• You always see your own record unmasked. The mask exists to protect you from viewers, not from yourself.
• Because the mask is a projection, an organization's policy change takes effect on the next read. It does not, and cannot, rewrite history.