pulse manifest

Audience: CLI users (and orchestration agents) discovering Pulse’s self-description — what commands exist, which aggregators are registered, which field types are supported, and what skills the binary ships with.

The manifest is the bare-pulse invocation with --json. It is deterministic and process-wide: it never depends on cohort data or the filesystem.

LLM agents using MCP: the manifest is also available via the pulse_manifest MCP tool. Agents typically call this once per session and cache the result.

Synopsis

pulse --json [--slim] [--intent ID]

(There is no pulse manifest subcommand — the manifest is the root command’s --json output.)

Flags

Flag	Type	Default	Purpose
`--json`	bool	false	Emit the manifest as a JSON envelope
`--slim`	bool	false	Drop prose descriptions from the manifest payload (smaller for size-sensitive clients)
`--intent`	string	“”	Scope the manifest to one intent-taxonomy ID (see below)

Manifest shape

From internal/descriptor/manifest.go:

{
  "format_version": "1.1",
  "data": {
    "commands":   [ /* every CLI leaf with a usage line */ ],
    "operators":  [ /* every aggregator / attribute / filterer / grouper / window / feature */ ],
    "tests":      [ /* every tier-1 statistical test */ ],
    "post_tests": [ /* every tier-2 post-test variant */ ],
    "distributions": [ /* every synth distribution kind */ ],
    "errors":     [ /* every registered error code with a description */ ],
    "mcp_tools":  [ /* every MCP tool name + description */ ],
    "field_types":[ /* every .pulse field type */ ],
    "skills":     [ /* every embedded skill with metadata */ ]
  },
  "errors":   [],
  "warnings": []
}

Every list is sorted deterministically (alphabetical or category + alphabetical). The same Pulse binary always emits the same manifest bytes (modulo --slim).

Intent-scoped manifest

--intent ID (MCP: pulse_manifest {"intent": ID}; library: Pulse.ManifestForIntent) narrows the manifest to one intent-taxonomy ID, for an agent that already knows the kind of question it is answering. The operator sections (components, tests, post_tests, regressions, matrices, overlays) keep only operators whose purpose names the intent, skills becomes the intent’s ranked skill list, and crosstab / matrix stay only when a remaining operator can use them. The fixed sections — commands, operations, the error-code lists, cohort_types, mcp_tools, synth_distributions, extensions, limits, components_schemas (each operator keeps its own component_schema) and the facet / process_chain / join / export / import blocks — are absent, never empty, and listed in elided. scope.intent carries the full intent record (label, sample phrasings, data shapes). Versions, digests, intents and return_presets are kept, so a client caches a scoped manifest under (pulse_version, feature_set_digest, limits_digest, scope.intent.id).

A scoped slim manifest is gated at no more than 15% of the full slim manifest for every analytic intent; describe (served by every summary aggregator) is the one named exception, with a measured ceiling. The unscoped manifest is unchanged.

Determinism gates

Several CI tests enforce manifest completeness — see Testing Conventions. Notably:

TestManifestOperatorsComplete — every registered operator appears in the manifest.
TestManifestTestsComplete / TestManifestPostTestsComplete — every registered statistical test appears.
TestManifestDistributionsComplete, TestManifestErrorCodesComplete, TestManifestMCPToolsComplete — same for distributions, error codes, and MCP tools.
TestManifestStreamableMatchesTypes — every operator’s streamable flag mirrors the per-type method.

When to use the manifest

Use case	Reach for
Discover what’s available	`pulse --json`
Confirm a specific operator’s params and emit type	`jq ’.data.operators[]
List embedded skills with their `applies_to`	`jq '.data.skills[]'`
Generate documentation or client stubs	Parse the full manifest once at boot
Quick “is this name a real operator?”	`pulse –json –slim

Exit codes

Code	Meaning
0	Always (the manifest is in-memory, deterministic, never errors)

Examples

Print the manifest

pulse --json | jq '.data | keys'

Slim variant for embedding in an agent’s system prompt

pulse --json --slim > manifest.slim.json

List every aggregator with its emitted type

pulse --json | jq '.data.operators[] | select(.category == "aggregation") | {name, emits_type}'

Confirm a feature operator’s parameters

pulse --json | jq '.data.operators[] | select(.name == "FEAT_BUCKETIZE")'

How LLMs Use Pulse — the manifest is one of the agent discovery primitives
Library: pulse.Manifest — Go counterpart
Internals: Architecture — why the manifest cannot import internal/service/ or internal/processing/

Keyboard shortcuts

Pulse Documentation