Release Notes

This is the running record of what ships in Pulse. It follows the same rule as the rest of the platform: entries are appended, never rewritten. A feature that was removed stays in the log, with a note saying it was removed.

Pulse is at its first release. The engineering model — events, verification, Build Cred, the graph — is complete and settled, and the surfaces that read it are live. Capabilities that are designed but not callable are named plainly in the reserved list below, rather than being quietly implied to exist.

A changelog on a platform whose entire premise is a trustworthy record has an obligation to be exact. This page is where we say what is real, what is reserved, and what we removed — in the same terms we would expect from a system we were being asked to trust with our own engineering history.

It would be easy to tidy this page — drop a feature that did not work out, adjust a date, soften a limitation once it is fixed. Every one of those edits makes the page less useful, and it would be indefensible on a platform that refuses to let its users edit their own history. We hold the changelog to the standard we hold the event log to, because the alternative is asking for a trust we are not willing to extend.

• Appended, not rewritten — corrections are new entries that supersede old ones. Both stay.
• Status is stated plainly — what is callable is documented as callable, and what is not is listed as reserved.
• Reserved is not shipped — a designed capability with no callable surface is listed as reserved, never as a feature.
• The verification engine is versioned separately, and every proof records the engine version that minted it.

The first release. The engineering model is complete and the platform surfaces that read it are live.

• Engineering Events — the append-only log, with the four verbs: PUSH, BLOCK, UNLOCK and PIVOT. PUSH is captured automatically and cannot be authored by hand.
• Verification — proofs minted from linked sources, graded L0 through L4, tamper-evident and versioned.
• Build Cred — derived, trust-weighted reputation across five dimensions: Delivery, Reliability, Resolution, Architecture, Collaboration.
• Projects and Organizations — execution containers with transferable ownership, and membership as a closable edge that never takes a developer's record with it.
• Knowledge — artifacts derived from resolved BLOCK/UNLOCK pairs, with the events and proofs behind them attached.
• The Engineering Graph — one connected model, read through rebuildable projections.
• Privacy Mask — provable but not leaked. Masking is applied per viewer when a projection is built, never by mutating the record.
• Pulse CLI — login, init, link, event, deploy, status, logs, config and sync.
• Platform surfaces — feed, event and project pages, organizations, explore, search, leaderboard, notifications, profile, settings, the Engineering Workspace, BLOCK rooms, bookmarks, onboarding, and these docs.

These are designed and named in the product. They are not available, and nothing in the documentation describes them as though they were.

• HTTP transport — the same contract the CLI serves, over HTTP. Reserved. Programmatic access today runs through the CLI, and the API Reference documents both against one resource model.
• Signed webhooks — at-least-once delivery with idempotency keys, driven by the outbox. Reserved.
• Documentation versioning — the docs platform reserves a version field. Today there is one version of these docs.

1. Check the version of the CLI you are running with pulse --version.
2. Read the entries above it to see what changed.
3. Check the reserved list before designing an integration around something you saw named in the UI.
4. For proofs, read the engineVersion on the proof itself — it records exactly which engine minted it.

The CLI is versioned independently of the platform, and proofs carry the engine version that minted them. When you need to know exactly what produced a record, the record tells you.

• Upgrade the CLI when you notice a new version; it is a global tool and there is nothing to coordinate.
• Read the reserved list before you design around a capability. Coming-soon means not callable.
• Trust the proof's engineVersion over any assumption about which rules applied to a historical event.

• Reading a reserved capability as an available one because it is named in the interface.
• Assuming a verification-engine upgrade re-grades your old proofs. It does not, deliberately — a proof means what it meant when it was minted.
• Pinning @pulse/cli as a project dependency to control its version. It is a developer tool; install it globally.

• Entries here are appended, never rewritten. A removed feature stays in the log with a note.
• The engineering model — events, verification, Build Cred, the graph — is settled. It is the part of Pulse least likely to change, by design.
• When the API ships, it will be versioned, and its release will be recorded here.