Elsa Core Documentation

The Weaver AI Copilot Platform is organized into development phases to implement an AI-driven assistant for Elsa workflows. The implementation follows a structured progression from core abstractions to user-facing features:

1. Phase 1: Setup: Establishes the project structure, including Elsa.AI.Abstractions, Elsa.AI.Host, Elsa.AI.Copilot, and Elsa.AI.Persistence.EFCore modules, along with their respective unit and integration test projects.
2. Phase 2: Foundational: Implements shared contracts, models (conversations, sessions, messages, tools, proposals, and audit events), and persistence layers using EF Core. This phase also introduces service registration, permissions, and tool enablement services.
3. Phase 3: User Story 1 (MVP): Enables authorized users to chat with 'Weaver' using workflow-aware context. Key features include streaming assistant events, tool lifecycle events, context resolution with authorization/redaction, and reconnection grace periods for durable output recovery.

Tasks are identified by an ID, priority [P], and a User Story label.

The Elsa.Secrets module provides a first-class system for managing immutable named secrets within Elsa. It replaces the legacy elsa-extensions secrets implementation with an Orchard-style system.

Key features include:

• Immutable Named Secrets: Secrets are identified by immutable technical names used as serialized references.
• Latest-Active Resolution: References automatically resolve to the latest active version of a secret.
• Pluggable Stores: Supports multiple storage backends including in-memory (for development), configuration-backed read-only stores (for deployment-managed values), and EF Core-based encrypted stores (for production).
• Extensible Secret Types: A registry system allows for different types of secrets.
• Security by Design: The system disallows user-initiated cleartext reveal after a secret has been created.
• Studio Integration: Includes management and picker UX for elsa-studio.

The Elsa.Diagnostics.ConsoleLogs module is an opt-in Core diagnostics feature designed to capture raw stdout and stderr line output. It provides a mechanism to redact sensitive information before it reaches providers, maintains a bounded recent history of logs, and exposes these logs via REST and SignalR contracts for real-time monitoring (e.g., in Elsa Studio).

Key characteristics:

• Redaction: Content is redacted and ANSI codes are stripped by default before being passed to providers.
• Buffering: Uses a bounded in-memory buffer for recent history and bounded subscriber queues for live streams.
• Transport: Uses REST endpoints for retrieving recent log history and source lists, and SignalR for live, mutable log subscriptions.
• Extensibility: Provides explicit extension points via IConsoleLogProvider, IConsoleLogRedactor, and IConsoleLogSourceRegistry to allow for future shared aggregation or custom redaction logic.

The Elsa.Diagnostics.OpenTelemetry module is an opt-in Core diagnostics module designed to act as an OTLP (OpenTelemetry Protocol) collector and API backend.

Key Functions:

• Receives OTLP telemetry (traces, metrics, logs, resources).
• Normalizes telemetry into Elsa diagnostics read models.
• Redacts sensitive values before data reaches provider boundaries.
• Stores recent telemetry in a bounded in-memory repository.
• Exposes authenticated REST APIs and SignalR live updates for real-time monitoring (e.g., for Elsa Studio).
• Publishes collector configuration metadata for standard OTEL senders.

Important Distinctions:

• This is a collector/API backend, not a producer-side workflow tracing middleware.
• It does not replace or modify the existing Elsa.Workflows.Core ActivitySource and Meter instrumentation, which remain the telemetry producers.
• It does not include durable database persistence in v1; it uses bounded in-memory storage.

The Secrets Module provides a first-class capability for managing sensitive information within Elsa Workflows and Elsa Studio. It replaces ad hoc secret handling with named secret references that are resolved at runtime.

Key characteristics include:

• Named References: Secrets are identified by immutable technical names. References always resolve to the latest active version of that name.
• Pluggable Stores: Secrets can be backed by different storage providers (e.g., Elsa-managed encrypted stores or configuration-backed read-only stores).
• Extensible Types: Supports various secret types and metadata.
• Security Model: To prevent exposure, cleartext secret values cannot be revealed via the API or Studio after creation. Users can only replace, rotate, use, test, or perform encrypted exports.
• Integration: Designed to be usable by other modules without those modules needing to know the underlying storage mechanism.