FaultMaven

AI Troubleshooting Copilot — run it yourself, or let us run it for you. Same engine either way: fair source (FSL-1.1-ALv2), self-hostable, and on FaultMaven Cloud with nothing to operate.

FaultMaven is an AI-powered troubleshooting copilot. It correlates the logs, metrics, and configs you share with runbooks, documentation, and past fixes to deliver contextual AI-driven incident investigation — answers grounded in your actual system, not generic guesses.

FaultMaven works a problem the way a seasoned engineer does — and never forgets what it learns:

• Goal-driven — it works toward a solution, not just a reply.
• Methodical — it follows a proven diagnostic method; it doesn't jump to conclusions.
• Evidence-based — every step is grounded in your data, and it shows its work.
• Self-learning — every problem it solves becomes knowledge it reuses.

Traditional observability tools tell you what broke. Generic LLMs guess why, but can't see your infrastructure. FaultMaven bridges this gap. Where predictive AIOps platforms act like actuaries — forecasting next quarter's outage probabilities from historical patterns — FaultMaven is the ER surgeon for systems already on the table.

---

Get started

This repository is the engine. There are two ways to run it, and it is the same engine either way — so whichever you choose, you are never locked in.

Let us run it	app.faultmaven.ai — FaultMaven Cloud: nothing to install or operate, plus team knowledge sharing. In beta: free, with a daily limit on investigation turns
Run it yourself	Quick Start — one command, free forever, fair source (FSL-1.1-ALv2). Your cases, evidence and knowledge base stay on your hardware
Just look	A complete investigation transcript, unedited — or join the Community Slack and @mention FaultMaven. Neither needs an account

• Check its work. FaultMaven runs on large language models. Its hypotheses, the data it asks for and the fixes it proposes can be incomplete, misleading or simply wrong — and it can be wrong confidently. FaultMaven proposes; you approve and execute. It has no access to your infrastructure and takes no action on your systems.
• It is beta software. Expect rough edges and occasional downtime. Provided as is, without warranty — see the Terms.
• Mind what you paste. FaultMaven stores the cases and files you give it, because reusing them is how it improves. Do not paste production secrets or customer data you would not want stored. The Community Slack is a shared, public workspace and runs under a FaultMaven-managed account rather than one of your own.
• Accounts do not merge. Sign up with a personal address now and move to a company one later, and that is a new account — there is no migration, and your beta cases do not follow you.
• Free during beta, with a daily limit. Each account gets a daily limit on investigation turns. Pricing will be announced before general availability.

Self-hosting is subject to none of this except the first point, which is a property of language models rather than of the deployment.

---

System Components

FaultMaven consists of an API and three ways to reach it:

Component	Repository	Purpose
FaultMaven API	This repo	Backend server: investigation engine, knowledge base, AI orchestration
FaultMaven Dashboard	faultmaven-dashboard	Web UI: knowledge base management, case history, settings
FaultMaven Copilot	faultmaven-copilot · Chrome Web Store	Browser extension: in-context troubleshooting overlay
FaultMaven Slack Agent	faultmaven-slack-agent · Community Slack	Answers in the incident thread

Typical usage: the Dashboard is the full product in a browser tab, and works end to end on its own. The Copilot extension puts the same investigation beside whatever page you are reading. The Slack agent answers where the incident is already being discussed. All three talk to the API backend.

---

Quick Start

One command. Budget 10–20 minutes on a first run — most of it pulling a 2.3 GB image that carries its own embedding model, which is what lets FaultMaven index and retrieve with no network at all. Subsequent starts take seconds.

Prerequisites

• Docker and Docker Compose
• LLM Provider (one of):
  • Hosted: OpenAI, Anthropic, Google Gemini (recommended — they enforce the structured output the investigation engine depends on), or Fireworks AI, Groq, Cohere, HuggingFace, OpenRouter
  • Local: an OpenAI-compatible endpoint (vLLM, Ollama) — see Local models; not yet verified end to end

Step 1: Start the Stack

# Clone the repository
git clone https://github.com/FaultMaven/faultmaven.git
cd faultmaven

# Configure your LLM provider — the ONLY thing you must set
cp .env.example .env
# Edit .env: set ONE provider's API key (e.g. GEMINI_API_KEY / OPENAI_API_KEY /
# ANTHROPIC_API_KEY). Everything else uses documented defaults, and the auth
# secret is auto-generated on first run.

# Start API + Dashboard (pulls pre-built images from GitHub Container Registry)
# This AUTOMATICALLY creates the database and a default admin user.
./faultmaven.sh start
# Or: docker compose up -d

What happens:

1. Docker pulls the images from GHCR (one-time, ~5.4 GB for the API — it bundles the embedding model and a starter Knowledge Base, so indexing and retrieval need no model download at runtime) and starts the services.
2. On first start (~1 minute) the API initializes the database, runs migrations, loads the bundled embedding model, and seeds 91 curated troubleshooting runbooks into the Knowledge Base. Restarts are faster — the database and vectors persist under ./data.
3. A default admin user is created: admin / [email protected]

First run is slower because of the one-time image pull. After that, startup is ~1 minute and needs no internet access for the embedding model or KB. Investigation turns still call the LLM provider you configured.

Local models

CHAT_PROVIDER=local with LOCAL_LLM_URL points FaultMaven at a self-hosted OpenAI-compatible endpoint (vLLM, or Ollama's /v1). The provider is wired in and its tool-calling check reads the endpoint rather than the model name, but we have not yet verified a full investigation end to end on an open-weights model, and local endpoints are best-effort for the structured output the engine depends on. Until a tested configuration is published here, use a hosted provider with strict structured output (Gemini, OpenAI, Anthropic) for CHAT_PROVIDER. If you try a local model, we want to hear how it went.

Step 2: Log In

1. Open http://localhost:3333
2. Select Dev Login
3. Enter username: admin

That's it! You are ready to go.

Optional: Create Additional Users

If you need more accounts, you can create them via CLI:

./faultmaven.sh create-user

Step 3: Install the Copilot Extension

1. Install FaultMaven Copilot from the Chrome Web Store — Chrome, Edge, Brave and other Chromium browsers
2. Click the extension icon → Settings → choose the Standalone (localhost) preset, or set the API URL to http://localhost:8090

The store build is the right one for self-hosting — it ships the presets and host permissions for a local or LAN backend. Self-hosting is about where this server runs, not which extension you install. Prefer to build it yourself? See the Copilot repository.

Step 4: Configure LLM Provider

Once logged in, go to LLM Settings in the Dashboard sidebar to verify your provider is connected:

1. Check that your configured provider shows a Connected status
2. Click Test Connection to verify the API key works
3. You can change your primary provider or update API keys directly from the Dashboard — changes take effect immediately without restarting

Note: LLM settings configured through the Dashboard are persisted in the database and take precedence over .env values. The .env file provides the initial configuration on first startup.

Step 5: Start Troubleshooting

1. Open the Dashboard at http://localhost:3333 to upload runbooks to your Knowledge Base
2. Navigate to any observability tool (AWS Console, Datadog, Grafana)
3. Click the Copilot extension icon and start troubleshooting

Docker Management Commands

Convenient scripts for managing the Docker-based stack:

# Main CLI for Docker-based deployment
./faultmaven.sh start              # Start services
./faultmaven.sh start --demo       # Start with demo data
./faultmaven.sh health             # Check service health
./faultmaven.sh logs               # View all logs
./faultmaven.sh logs api           # View specific service logs
./faultmaven.sh restart            # Restart all services
./faultmaven.sh stop               # Stop all services
./faultmaven.sh clean              # Remove containers (PROTECTS ./data)
./faultmaven.sh clean --wipe-data  # Remove containers AND delete all data

By default the stack runs pre-built images from GHCR (ghcr.io/faultmaven/faultmaven and …/faultmaven-dashboard). Pin versions with FM_IMAGE_TAG / FM_DASHBOARD_IMAGE_TAG in .env, or refresh to the latest published images with ./faultmaven.sh start --pull.

Building from source (contributors):

./faultmaven.sh start --build              # Build the API from this repo, then start
./faultmaven.sh start --build-dashboard    # Also build the Dashboard from ../faultmaven-dashboard

--build-dashboard needs the Dashboard repo checked out alongside this one (git clone https://github.com/FaultMaven/faultmaven-dashboard.git ../faultmaven-dashboard). For pure backend development without Docker, use ./scripts/faultmaven-dev.sh start.

Access Points

Component	URL	Description
Dashboard	http://localhost:3333	Web UI for KB management, case history, LLM settings
API	http://localhost:8090	REST API
API Docs	http://localhost:8090/docs	Interactive OpenAPI documentation

Alternative: Local Development Setup

For contributors or debugging, you can run the components as local processes instead of Docker.

1. Start the API Backend:

# Start API as local process
./scripts/faultmaven-dev.sh start

# Verify it's running
./scripts/faultmaven-dev.sh health

The API will be available at http://localhost:8090

2. Start the Dashboard (separate process):

The dashboard is in a separate repository. To run it locally:

# Clone the dashboard repository (if not already cloned)
git clone https://github.com/FaultMaven/faultmaven-dashboard.git
cd faultmaven-dashboard

# Install dependencies
npm install
# Or: pnpm install

# Configure API endpoint (optional - defaults to http://localhost:8090)
cp .env.example .env
# Edit .env if needed: VITE_API_URL=http://localhost:8090

# Start the development server
npm run dev
# Or: pnpm dev

The dashboard will be available at http://localhost:5173 (Vite dev server) and will connect to the API at http://localhost:8090.

Note: Make sure the API backend is running before starting the dashboard. The dashboard requires the API to be available at http://localhost:8090.

Local Development Management Commands

Convenient scripts for managing the local development environment:

# For contributors developing FaultMaven
./scripts/faultmaven-dev.sh start   # Start API as local process
./scripts/faultmaven-dev.sh stop    # Stop the API
./scripts/faultmaven-dev.sh restart # Restart the API
./scripts/faultmaven-dev.sh health  # Run comprehensive health checks
./scripts/faultmaven-dev.sh logs    # Stream application logs
./scripts/faultmaven-dev.sh test    # Run tests (delegates to scripts/tests.py)

For more detailed setup instructions, see Development Setup.

---

Why FaultMaven?

FaultMaven is not a chatbot wrapper; it is a context-aware investigation engine, built to solve, not to chat — and designed to get smarter with every incident. It is a copilot, not an autopilot: every step it suggests is yours to run, review, or reject. You stay in command of the keyboard.

1. Deep Context Awareness

Generic chatbots can't access your logs, configs, or deployments. FaultMaven correlates your full stack context—connecting errors with recent changes, configuration drift, and system state to find root causes faster.

Example: A Kubernetes pod is crashlooping. ChatGPT gives generic advice. FaultMaven analyzes your pod logs alongside deployment YAMLs and recent changes—then identifies that a ConfigMap update 2 hours ago introduced an invalid environment variable.

2. Zero Context-Switching

Stop copying errors between browser tabs. The FaultMaven Copilot browser extension overlays AI troubleshooting directly onto your existing tools—AWS Console, Datadog, Grafana, or localhost. No backend agents, webhooks, or complex integrations required. Because the Copilot lives in your browser, it never asks for production API keys, root credentials, or read/write access to your live systems — you supply the context it sees, nothing more.

How it works: FaultMaven lives in your browser, not your cluster. As you view logs in CloudWatch, traces in Datadog, or pods in the Kubernetes dashboard, the Copilot extension captures the relevant context and correlates it with your Knowledge Base in real-time.

3. The Knowledge Flywheel

Most troubleshooting knowledge is lost once the incident is closed. FaultMaven turns that lost data into a growing asset through a "Seed & Grow" lifecycle:

• Seed with Runbooks: You don't start from zero. Pre-load your existing runbooks and documentation into the Knowledge Base so the AI knows your standard operating procedures from Day 1.
• Grow with Incidents: As you troubleshoot, the AI learns. When a case is resolved, FaultMaven offers to turn it into a runbook — but only if the case clears an explicit bar: a verified problem definition, a confirmed root cause (one that was counterfactually borne out, not merely plausible), and an actionable solution. A case that doesn't clear that bar is never written to the Knowledge Base, so a wrong or half-finished conclusion can't become the guidance someone follows next time.
• Result: Your static documentation becomes a living asset. The solution to today's incident becomes the starting point for tomorrow's.

4. Opportunistic Investigation Framework

FaultMaven investigates methodically — verify the symptom, form hypotheses, test them against evidence, then fix — and never jumps to conclusions. But methodical doesn't mean rigid: it uses an opportunistic investigation approach where the agent completes tasks based on data availability rather than following rigid sequential phases.

Core Principles:

• Milestone-based progress - Track what's completed, not what phase you're in. Complete multiple milestones in one turn when data allows.
• Linear stage flow - Both investigation paths (MITIGATION_FIRST, ROOT_CAUSE) follow 1→2→3→4 progression.
• Mitigation as a tool - Quick fixes available during early stages without disrupting the investigation flow.

Case Lifecycle: INQUIRY → INVESTIGATING → RESOLVED / CLOSED

Key Components:

• MilestoneEngine - Tracks verification, investigation, and resolution milestones opportunistically.
• WorkingConclusionGenerator - Continuous progress tracking to prevent circular reasoning.
• MemoryManager - Hot/warm/cold memory tiers to maintain context across long investigations.

5. Flexible Multi-LLM Support

FaultMaven is architected to be model-agnostic, giving you the freedom to choose the best intelligence for your specific needs and budget.

It supports a wide variety of backends, including:

• Frontier Models: Connect to major cloud providers (OpenAI, Anthropic, Google) for complex reasoning and multimodal analysis.
• Inference Providers: Use high-speed inference engines (Groq, Fireworks AI) for low-latency responsiveness.
• Local & Self-Hosted: Point FaultMaven at a local OpenAI-compatible runner (vLLM, Ollama). Wired in, but not yet verified end to end on an open-weights model — see Local models.
• Model Routing: Built-in fallback logic ensures high availability by automatically switching providers if the primary API becomes unavailable.

---

Deployment Modes

FaultMaven runs on a single, deployment-agnostic Core. The same engine powers two deployment architectures — what differs is the infrastructure footprint and who operates it, not the investigation engine itself. The Core is source-available (FSL-1.1-ALv2) in every mode.

1. Standalone (Self-Hosted)

Best for: Engineers who want FaultMaven on their own hardware, contributors, and anyone who wants to audit exactly what runs.

Standalone is a monolithic, single-instance deployment you run on your own hardware — directly as a server process or inside a Docker container. It ships with fixed, simple defaults (SQLite, in-process FakeRedis, embedded ChromaDB) so getting started is "pick an LLM provider, paste a key, go."

• Self-Hosted: You own and operate the stack — the container, the database (SQLite), and the configuration via a single .env file.
• Build Your Own Knowledge: Ingest your own runbooks and build a Personal Knowledge Base tailored exactly to your specific needs.
• Your Data Stays Put: Cases, evidence and the knowledge base live on your disk, and retrieval runs with no network (the embedding model ships in the image). Prompts go to the LLM provider you configure — see Local models for where self-hosted inference stands.
• Single User: Standalone has no team sharing; the team knowledge scope needs Cloud's multi-tenancy.

Follow the Quick Start guide above to get up and running.

2. Cloud (FaultMaven-Hosted SaaS)

Best for: Individuals and teams who would rather use FaultMaven than operate it.

Cloud is FaultMaven run for you: the same engine as Standalone, with nothing to install or operate, plus team knowledge sharing. In beta it is free, with a daily limit on investigation turns; pricing will be announced before general availability. Because the engine is fair source, you are never locked in — you can run the same engine yourself at any time.

"Cloud" describes the architecture, not the location. The same cloud-native deployment can run in public cloud (AWS/GCP/Azure) or on-prem as a private cloud.

• Managed Infrastructure: We run the Core on Kubernetes with PostgreSQL, Redis and object storage, and handle upgrades. Cloud is deployed on its own schedule, so it can run an older build than the current self-hosted image.
• Team Knowledge Sharing: Multi-tenancy adds the team knowledge scope — share personal runbooks across your org. (Both deployments ship with the same global runbook pack.)
• Collaborative 3-Tier Knowledge: The cloud platform activates the full 3-scope model:
  1. Global: System-wide runbooks shipped to every deployment.
  2. Team: Runbooks shared across your organization (Institutional Memory).
  3. Personal: Your private runbooks and drafts.

Comparison

Feature	Standalone (Self-Hosted)	Cloud (FaultMaven-Hosted)
Configuration	Single-User / Docker	Multi-User / Managed K8s
Knowledge Base Start State	Ships with the global runbook pack	Ships with the global runbook pack
Knowledge Scopes	Global + Personal	Global + Team + Personal (team sharing)
LLM Configuration	Dashboard-managed (single provider, BYOK)	Dashboard-managed (multi-provider fallback chain, hot-reload)
Case Management	Full (with archive)	Full (with archive + org-wide view)
User Management	Not applicable (single user)	Full CRUD, invite, roles
Infrastructure	Fixed defaults (SQLite, FakeRedis, embedded ChromaDB)	Fully Managed (Postgres, Redis, S3)
Security	Local Auth	SSO (SAML/OIDC), enterprise isolation (RLS), teams
Session Persistence	Ephemeral (FakeRedis, resets on restart)	Persistent (Redis, saved across sessions)
Access	http://localhost:3333 (localhost only)	https://app.faultmaven.ai

Cloud beta is open — sign up at app.faultmaven.ai with your email. Free while it is in beta, with a daily limit on investigation turns; pricing will be announced before general availability.

---

Architecture

FaultMaven is a monolithic application with clean Vertical Slice Architecture. Instead of separating by technical layers (Controller, Service, Dao), we organize by Feature Modules.

                    Browser Extension / Dashboard
                              |
                            HTTPS
                              v
+------------------------------------------------------------------+
|                      FaultMaven API (8090)                       |
|                                                                  |
|  +------------------------------------------------------------+  |
|  |                       API Layer                            |  |
|  |   /api/v1/agent   /api/v1/cases   /api/v1/knowledge  ...   |  |
|  +------------------------------------------------------------+  |
|  |                     Service Layer                          |  |
|  |   AgentService  CaseService  KnowledgeService  AuthService |  |
|  +------------------------------------------------------------+  |
|  |                  Infrastructure Layer                      |  |
|  |   LLM Router   Persistence   Security   Observability      |  |
|  +------------------------------------------------------------+  |
+------------------------------------------------------------------+
         |                     |                     |
         v                     v                     v
    +--------+           +---------+           +----------+
    | Redis  |           |ChromaDB |           | SQLite/  |
    | (opt)  |           |(Vectors)|           | Postgres |
    +--------+           +---------+           +----------+

Modules

Module	Description
agent	Investigation orchestration, AI tools
auth	Users, sessions, organizations, teams, RBAC
case	Investigation cases and lifecycle management
evidence	Evidence storage, linking, and retrieval; file storage adapters (raw uploads land in uploaded_files via case turns)
knowledge	Embeddings, vector search, RAG, knowledge items
report	Report generation and recommendations

---

Project Structure

faultmaven/
├── faultmaven/              # Main application
│   ├── main.py              # FastAPI entry point
│   ├── api/                 # Shared API middleware, dependencies
│   ├── modules/             # Vertical slice feature modules
│   │   ├── agent/           # Investigation + AI tools
│   │   ├── auth/            # Authentication + authorization
│   │   ├── case/            # Case management
│   │   ├── evidence/        # Evidence/file handling
│   │   ├── knowledge/       # Knowledge base + RAG
│   │   └── report/          # Reporting
│   ├── config/              # Settings (single env-read point)
│   ├── container/           # Dependency injection
│   ├── infrastructure/      # Shared adapters (LLM, DB, storage)
│   ├── core/                # Core domain logic
│   └── services/            # Service layer
├── tests/                   # Test suite
│   ├── unit/
│   ├── integration/
│   ├── health/
│   └── performance/
├── docs/                    # Documentation
├── alembic/                 # Database migrations
├── faultmaven.sh            # Docker CLI wrapper (start/stop/health/logs)
├── docker-compose.yml       # Local services
├── Dockerfile               # Container image
├── pyproject.toml           # Dependencies and tools
└── .env.example             # Configuration template

---

Configuration

Environment Variables

Create a .env file from the template:

cp .env.example .env

FaultMaven has two configuration layers:

Layer	What it configures	How to change
Environment (.env)	Infrastructure: database, auth mode, Redis, CORS, ports	Edit .env file, restart the server
Dashboard (DB-backed)	LLM settings: provider, API keys, fallback chain	Change via Dashboard UI, takes effect immediately

On first startup, LLM settings are loaded from .env. Once you modify them through the Dashboard, the database becomes the source of truth for LLM configuration. Infrastructure settings always come from .env.

Infrastructure Settings (.env)

Category	Variables	Description
Database	DATABASE_URL	SQLite (default) or PostgreSQL
Sessions	REDIS_HOST, REDIS_URL	FakeRedis (default) or real Redis
Vectors	VECTOR_STORAGE_TYPE, CHROMADB_URL	chromadb (default, local PersistentClient); set CHROMADB_URL for an external server
Security	JWT_SECRET_KEY, CORS_ALLOW_ORIGINS	Auth and CORS settings

See .env.example for all options with detailed comments.

LLM Provider Setup

Set your initial LLM provider in .env:

# Select primary provider
CHAT_PROVIDER=openai  # openai, anthropic, fireworks, gemini, groq, cohere, huggingface, openrouter, local

# Add API key for your provider
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
FIREWORKS_API_KEY=fw-...
GROQ_API_KEY=gsk-...
COHERE_API_KEY=xxx
HUGGINGFACE_API_KEY=hf_...
OPENROUTER_API_KEY=sk-or-...

# Optional: Separate providers for specific tasks
MULTIMODAL_PROVIDER=gemini       # Visual evidence processing
SYNTHESIS_PROVIDER=openai        # RAG document queries

After the first startup, you can manage all LLM settings (provider, API keys, fallback chain) through the Dashboard > LLM Settings page. Changes are hot-reloaded — no server restart required.

Fallback Chain: Primary provider -> Fireworks -> OpenAI -> Local

---

Development

Testing

# Run all tests (local dev runner)
./scripts/faultmaven-dev.sh test

# Run a subset
./scripts/faultmaven-dev.sh test --unit

# Or use pytest directly
pytest tests/unit/
pytest --cov=faultmaven

Code Quality

# Linting — the same line CI runs. Do not add `--select`: it REPLACES
# [tool.ruff.lint].select in pyproject.toml rather than narrowing it.
ruff check faultmaven/ tests/

# Formatting — CI runs `black --check faultmaven/ tests/`. Import sorting is
# ruff's `I` rules (ruff replaced isort in #179); do not run `isort`.
black faultmaven/ tests/

# Type checking (not a CI gate; `ignore_errors = true` in pyproject.toml)
mypy faultmaven/

Database Migrations

# Create migration
alembic revision --autogenerate -m "description"

# Apply migrations
alembic upgrade head

---

Tech Stack

Layer	Technologies
Framework	Python 3.11.5+, FastAPI, Uvicorn, AsyncIO
LLM/AI	OpenAI, Anthropic, Fireworks, Gemini, Groq, Cohere, HuggingFace, OpenRouter
Database	SQLAlchemy 2.0, SQLite (standalone), PostgreSQL (cloud), Alembic
Vector DB	ChromaDB, sentence-transformers
Cache	Redis (cloud), FakeRedis (standalone — full API parity)
Auth	JWT (PyJWT), bcrypt, RBAC
Observability	Opik tracing, Prometheus metrics, structlog
Testing	pytest, pytest-asyncio, pytest-cov

---

User Interfaces

FaultMaven provides two frontend interfaces. For setup instructions, see Quick Start or Local Development Setup.

Dashboard

FaultMaven Dashboard - Web application for proactive knowledge management:

• Knowledge Base Management: Upload runbooks, search indexed documents, archive and restore items
• Case Management: View, search, filter, and annotate past investigations. Archive resolved cases for long-term reference
• LLM Settings: View provider status, test connections, change primary provider, and update API keys — all changes take effect immediately without restarting

Browser Extension (Copilot)

FaultMaven Copilot — browser extension for reactive troubleshooting, available on the Chrome Web Store:

• Context Capture: Reads logs, stack traces, and dashboards directly from your screen
• In-Flow Diagnostics: Troubleshoot within AWS Console, Datadog, Grafana, and other tools
• Knowledge Base Integration: References your documentation in real-time
• Session Continuity: Maintains chat history across browser sessions

Building from Source

For development or customization, see the respective repositories:

• Dashboard Development
• Copilot Development

---

Documentation

Document	Description
docs/README.md	Documentation index
docs/architecture/	System design and ADRs
docs/guides/	How-to guides
docs/development/	Development standards
docs/operations/	Runbooks and monitoring

---

Contributing

See docs/CONTRIBUTING.md for:

• Development setup
• Coding standards
• Testing requirements
• PR guidelines

---

License

FSL-1.1-ALv2 (Functional Source License) — source-available, converting to Apache-2.0 two years after each release. See LICENSE for details.

---

Support

• Issues: GitHub Issues
• Discussions: GitHub Discussions
• Email: [email protected]