Skip to main content

UbID Pulse

UbID Pulse is the product domain for observability, service posture, and operational evidence. It helps authorized teams understand whether identity services are healthy, whether trust controls are being enforced, and whether an event requires investigation or response.

Operational trust requires more than uptime. A credential service may be reachable while a signing key is unavailable, a status source is stale, a proofing dependency is degraded, or a recovery control is failing. Pulse correlates technical and trust signals so that the platform can be operated accountably.

What Pulse observes​

Depending on the deployment, Pulse may correlate:

  • service health and availability;
  • performance and capacity indicators;
  • credential issuance and verification outcomes;
  • credential-status and metadata freshness;
  • authentication and device-lifecycle events;
  • key state and approved cryptographic-operation evidence;
  • proofing and external dependency posture;
  • recovery-stage events;
  • security alerts and policy rejections;
  • deployment, backup, and restoration evidence.

Sensitive identity content and secret material should not be required for ordinary operational visibility.

Metrics, alerts, audit, and evidence​

These functions are related but not interchangeable:

  • Metrics summarize measured system behavior.
  • Dashboards visualize selected metrics and trends.
  • Alerts route conditions that require attention.
  • Audit records capture who or what performed a governed action.
  • Evidence artifacts connect observations, policy decisions, and outcomes for later review.

A dashboard is not the authoritative record of an identity decision. Source events, health checks, policy results, and signed or checksummed evidence remain the operational truth.

Explainable service posture​

Pulse should help an authorized operator answer questions such as:

  • Which capability is affected?
  • Is the issue technical, cryptographic, trust-related, or dependency-related?
  • What user or institutional journeys are impacted?
  • Which policy or control detected the condition?
  • What evidence supports the conclusion?
  • Has the condition recovered, and was recovery verified?

The goal is actionable understanding without exposing unnecessary personal data.

Privacy-aware operations​

Operational visibility must follow data minimisation. Pulse should prefer:

  • scoped identifiers rather than universal identity records;
  • aggregated metrics where individual detail is unnecessary;
  • event references rather than secret or credential payloads;
  • controlled access to sensitive evidence;
  • retention based on operational and legal purpose;
  • separation between troubleshooting, audit, analytics, and business reporting.

Relationship with other products​

Pulse receives governed signals from across the portfolio:

  • UbID Credential Cloud for issuance and lifecycle posture;
  • UbID Proof for proofing health and outcomes;
  • UbID Access for authentication and device events;
  • UbID Recover for recovery stages and controls;
  • UbID Connect for protocol and dependency posture;
  • UbID KeyVault for key state and cryptographic evidence;
  • UbID Sentinel AI for evidence-based interpretation.

What Pulse does not do​

Pulse observes and communicates state. It does not silently change credential status, release recovery material, rotate keys, or override policy merely because an alert fired.

Operational action must follow authorized runbooks, policy, approvals, and evidence requirements.

Public documentation boundary​

Public documentation explains observability concepts and evidence responsibilities. Dashboards, hostnames, ports, private metrics, alert thresholds, customer incident data, security weaknesses, and operational runbooks remain restricted.

See also Auditability and Observability, Security Model, and UbID Sentinel AI.