Files
pulse/docs
rcourtman 97a30b0600 Introduce the Patrol execution profiles: detection and investigation
Execution posture is now profile-owned through the core-only,
never-serialized tools.ExecutionProfile. Both Patrol profiles are
non-interactive, deny infrastructure mutations, and clear any inherited
autonomous mode. Detection restricts pulse-state mutations to an
explicit allowlist of the finding lifecycle tools - a blanket
pulse-state allowance would also permit alert dismissal and knowledge
writes - while investigation denies all pulse-state mutations, keeping
it structurally read-only. InvocationPolicy gains the allowlist and
Allows() is now tool-name-aware.

Chat turns build ONE effective request executor (control level,
autonomy, profile, resolved context) BEFORE provider projection and
clone that executor per provider attempt, reversing the previous
project-from-base-then-clone order so the offered schema and the
runtime boundary always agree. Scheduled Patrol (ExecutePatrolStream)
now runs under the detection profile instead of autonomous mode -
closing its direct view of Docker/Kubernetes mutation subactions - and
ListAvailableTools projects through the identical path.
toolsForExecutionMode's mode booleans are replaced by the profile on
the executor itself.

Non-interactive profiles independently hide pulse_question from the
manifest AND runtime-block it before the interactive-call-set special
case: a fabricated question call returns a non-interactive error
without emitting a waiting event, and sibling tool calls from the same
provider turn keep processing. Approval waits never block for
non-interactive profiles (they queue), and the tool-only-turn wrap-up
guardrail is interactive-profile-owned instead of keyed on autonomy.
The system prompt describes detection and investigation modes directly
rather than claiming controlled or autonomous execution; the
investigation prompt directs the model toward typed action proposals.

Proofs: detection allowlist enforcement (alerts resolve and knowledge
remember blocked, finding tools allowed, projection agrees),
investigation structural read-only (patrol mutation tools dropped from
the manifest and blocked at runtime), profile clone isolation, profile
prompt modes, and question-tool hiding across profiles.
2026-07-10 15:53:38 +01:00
..
…
2026-07-01 09:55:35 +01:00
2026-07-09 11:52:28 +01:00
2026-07-02 11:50:03 +01:00
2026-06-02 19:14:18 +01:00
2026-07-02 11:50:03 +01:00
2026-07-01 09:55:35 +01:00
2026-06-02 19:14:18 +01:00
2026-07-09 11:52:28 +01:00
2026-06-04 14:07:14 +01:00
2026-07-09 11:52:28 +01:00

📚 Pulse Documentation

Welcome to the Pulse documentation portal. Here you'll find everything you need to install, configure, and master Pulse.


v6 Execution Canonical Source

For Pulse v6 build/release execution work, do not start from this broad docs index. Use:

  1. docs/release-control/v6/internal/SOURCE_OF_TRUTH.md for stable human governance and locked decisions
  2. docs/release-control/v6/internal/status.json for live lane state, lane-to-subsystem ownership, structured evidence references, typed lane/subsystem decision records, and canonical ordered lists
  3. docs/release-control/v6/status.schema.json for the machine-readable status contract
  4. docs/release-control/v6/internal/subsystems/registry.json and docs/release-control/v6/internal/subsystems/registry.schema.json for subsystem ownership, explicit shared-ownership exceptions, and proof-routing rules
  5. python3 scripts/release_control/status_audit.py --check if you need a machine-derived evidence health audit
  6. python3 scripts/release_control/registry_audit.py --check if you need a machine-derived subsystem registry audit
  7. python3 scripts/release_control/contract_audit.py --check if you need a machine-derived subsystem contract audit, including explicit cross-subsystem dependency checks and exact registry-derived shared-boundary wording Local pre-commit runs the v6 machine audits against staged control-file content so partial staging cannot hide governance drift. Local pre-commit also blocks partial staging for hook-sensitive governance files under docs/release-control/v6/, scripts/release_control/, internal/repoctl/, .husky/pre-commit, and .github/workflows/canonical-governance.yml, because those checks still execute or structurally read the working-tree versions locally.
  8. python3 scripts/release_control/subsystem_lookup.py <path> [<path> ...] --pretty --lean if you need subsystem ownership, proof routing, exact contract-focus lines, and compact lane context for a change

For governed runtime changes, a staged subsystem contract only counts if its diff updates a substantive contract section such as Purpose, Canonical Files, Shared Boundaries, Extension Points, Forbidden Paths, Completion Obligations, or Current State, rather than metadata alone.

All other documents are supporting references unless explicitly required for evidence.


🚀 Getting Started

  • Localized getting started: Deutsch • Español. These first-wave pages cover the public install path and preserve commands, config keys, image names, activation keys, and product identifiers exactly.
  • Installation Guide Step-by-step guides for Docker, Kubernetes, and bare metal.
  • Configuration
    Learn how to configure authentication, notifications (Email, Discord, etc.), and system settings.
  • Deployment Models
    Where config lives, how updates work, and what differs per deployment.
  • Migration Guide
    Moving to a new server? Here's how to export and import your data safely.
  • Upgrade to v6
    Practical upgrade guidance and post-upgrade checks for Pulse v6.
  • FAQ Common questions and quick answers.

🛠️ Deployment & Operations

🔐 Security

  • Security Policy – The core security model (Encryption, Auth, API Scopes).
  • Privacy – What leaves your network (and what doesn’t).
  • OIDC / SSO – OIDC Single Sign-On configuration (Authentik, Keycloak, Azure AD, etc.).
  • Proxy Auth – Authentik/Authelia/Cloudflare proxy authentication configuration.
  • Agent Security – Agent privilege model, Proxmox API-only choices, and self-update verification.

📖 Advanced Topics (Relay / Pro / legacy Pro+ / Cloud)

  • AI Modes & Safety – Configure Patrol mode, assistant control levels, investigation tuning, and safety guardrails.
  • Role-Based Access Control (RBAC) – Define custom roles, assign permissions, and integrate with OIDC group mapping.
  • Audit Logging – Tamper-evident event logging for compliance, with query, export, and signature verification.

✨ New in 6.0

💳 Plans (Community / Relay / Pro / Cloud)

Pulse is available in three self-hosted tiers plus hosted Cloud:

  • Community: Free self-hosted monitoring with core monitoring included and 7-day history.

  • Relay: Adds secure remote access to the Pulse web UI, Pulse Mobile pairing for handoff, push notifications, and 14-day history.

  • Pro: Adds hands-on Patrol modes, issue investigation, governed fixes, verified outcomes, operations tooling, governance features, and 90-day history.

  • Cloud: Hosted Pulse with Pro-level capabilities; hosted pricing is unchanged by the self-hosted model lock.

  • Learn more at pulserelay.pro

  • Plans and entitlements (includes the Community/Relay/Pro/Cloud matrix)

  • AI deep dive

  • Multi-Tenant Organizations (Enterprise) — Isolate infrastructure by organization for MSPs and multi-datacenter deployments.

📡 Monitoring & Agents

💻 Development

📁 Previous Versions


Found a bug or have a suggestion?

GitHub Issues