Availability: Issues is a Beta feature available on Enterprise and Cloud Pro plans. It is off by default and must be enabled by an organization admin.
- AI-filed findings — every AI agent turn is scanned in the background; likely-wrong answers are grouped by root cause and filed automatically.
- Human-filed issues — anyone with access can report a problem straight from a chart, dashboard, tile, or the board itself.
When to use it
Turn Issues on once you have agents in regular use and want a shared queue for data-quality work. It’s most useful when:- Users ask the same kind of question repeatedly and the agent struggles
- You want to keep dbt metadata and agent instructions tight as your data model evolves
- You’re rolling agents out to a wider audience and want admin-level visibility into quality
- You want a single place to triage data problems users spot in dashboards or charts
Enabling Issues
Issues is opt-in. Until an admin enables it, no agent turns are processed and no findings are collected.- Go to Settings → Ask AI → General.
- Toggle Review AI agent turns on.
Opening the board
Open Settings → Ask AI → Issues to see the board. The Ask AI button in the navbar is the fast path: when there are open issues it previews recent findings; when the board is empty it shows a small dropdown that links straight to the Issues board so newly-filed manual issues are always reachable. Cards on the board are grouped by status lane (To Do, In Progress, Done) and each card shows its priority, assignee, and category badge. Click a card to open the issue detail modal.How issues get onto the board
AI-filed findings
With the setting enabled, Lightdash scans every AI agent turn for signs the answer was probably wrong — a missing metric, an ambiguous field, a gap in your project context — and files an issue for each root cause it identifies. Before filing, the classifier checks the board’s existing issues and, if the same underlying problem is already tracked, attaches the new evidence to that issue instead of opening a duplicate. Recurring findings bump the Recurs N× tag on the existing card. Slack notifications (if configured) only fire when a new issue is opened. Recurrences accrue silently on the existing card so a chatty problem doesn’t spam the channel — check the board for the latest state. AI findings are opened in the same lane your triage workflow uses (existing findings behavior is unchanged).Human-filed issues
Any organization admin with AI agents enabled can file an issue from several places:- The New issue button on the Issues board.
- The Create issue item in the 3-dot menu on a dashboard header.
- The Create issue item in the 3-dot menu on a chart or explore header.
- The Create issue item in the 3-dot menu on a dashboard chart tile.
- The Create issue action on a resource row in Spaces and Home.
Filing an issue
The Create issue modal captures:| Field | Description |
|---|---|
| Title | Short summary of the problem. |
| Description | Markdown-supported detail. Doubles as the “desired outcome” the writeback agent reads. |
| Project | The project the issue belongs to. Locked when filed from a chart, dashboard, or tile. |
| Priority | urgent, high, medium, low, or none. |
| Assignee | The person responsible for triaging the issue. |
| Agent | The AI agent that owns the affected models. Click Suggest to pre-select the best-fit agent — Lightdash uses the same AI router as Ask AI, routing your title and description to pick an agent and showing its reasoning as a hint. Clearing the agent clears the hint. |
| Related explores | Multi-select of the explores the issue is about. Pre-seeded with the chart’s base explore when filed from a chart. Feeds the writeback prompt so the agent edits the right YAML. |
The issue detail modal
Clicking a card opens a focused modal with a metadata rail (status, priority, assignee, agent, project) and a chronological activity feed that merges issue events with any existing writeback events:createdstatus_changedassignee_changedpriority_changedcomment_addedrecurred
Recurs N× tag next to the category badge, and — if writeback is blocked — a plain-language note explaining why (for example, that a GitHub or GitLab connection is required).
Fixing an issue with writeback
For each issue, Lightdash proposes the smallest change that would prevent it:- Semantic layer fixes open a pull request against your dbt project (rename a field, add a description, add a metric).
- Project context fixes add a short note to a shared file that your agents read before answering future questions.
- a root cause of semantic layer or project context,
- a project, and
- an assigned agent.
| Issue type | What it means | How to fix |
|---|---|---|
| Semantic layer | A field, metric, or description is missing, ambiguous, or wrong in your dbt project. | Run writeback to open a pull request against your dbt repository. |
| Project context | Your agents are missing background knowledge to answer reliably (e.g. which table to use for “active customers”). | Run writeback to add a note your agents read before answering. |
The lightdash.project_context.yml file
Project context fixes don’t touch your dbt models. Instead, they write to a separate file — lightdash.project_context.yml — that lives next to lightdash.config.yml inside your dbt project directory. Your AI agents read it before they answer, so notes you add here change future behavior without changing the semantic layer.
The file is committed to your dbt repo and travels with the rest of your project metadata. The first time a project context fix runs, it creates the file (with a header explaining what it’s for) and opens a pull request. Subsequent fixes add or update entries in the same file.
The full JSON Schema is published at lightdash-project-context-1.0.json — point your editor at it for autocomplete and validation.
File shape
lightdash.project_context.yml
{ version, entries }. A bare array of entries is also accepted for backward compatibility, but new files are written in the canonical shape.
Top-level properties
| Property | Type | Required | Description |
|---|---|---|---|
version | number | yes | Schema version. Currently always 1. Bumping this is the escape hatch for a future breaking change. |
entries | array | yes | The list of context entries. May be empty. |
Entry properties
Each item inentries is a single self-contained fact your agents should know.
| Property | Type | Required | Description |
|---|---|---|---|
kind | "definition" | "context" | yes | How the entry is retrieved. Use definition for term-triggered facts (acronyms, vocabulary, “X means Y”). Use context for object-scoped guidance (routing rules, join rules, durable facts about a model). |
content | string | yes | One self-contained sentence. This is what the agent reads. Keep it short and unambiguous. |
id | string | no | Stable identifier used to update the entry later. Optional — Lightdash derives one from terms[0] (or content) at ingest if you omit it, suffixing on collision. Provide an explicit id if you want to hand-edit later without worrying about churn. |
terms | string[] | no | Prompt-facing trigger words and phrases. Used to surface definition entries when a user’s question mentions one of them. Defaults to []. |
objects | string[] | no | Semantic objects (models, fields, joins) this entry concerns. Used to surface context entries when the agent is reasoning about one of these objects. Defaults to []. |
Editing the file
You can editlightdash.project_context.yml directly — it’s a normal file in your dbt repo. The Issues flow is designed to coexist with manual edits: writeback uses the GitHub API to merge a single entry at a time, preserving comments, quoting, and key order in the rest of the file, so the resulting diff is just the changed entry.
If you do edit by hand, the same validation rules apply: invalid files surface schema-backed errors at ingest time.
Project context vs. semantic layer fixes
Both kinds of fix open a pull request, but they change different things and have different review costs.| Semantic layer fix | Project context fix | |
|---|---|---|
| What it changes | Your dbt model YAML — renames a field, adds a description, adds a metric, fixes a join. | A single entry in lightdash.project_context.yml. |
| Who else sees the change | Everyone querying the model, in Lightdash and downstream. | AI agents only. |
| How the PR is built | A writeback agent runs in a sandbox against your dbt project and proposes the edit. | Deterministic merge into the YAML file via the GitHub API — no sandbox. |
| When to use it | The data model itself is wrong, ambiguous, or under-described. The fix would help SQL users too, not just the agent. | The data model is fine, but the agent is missing background knowledge — terminology, which table to prefer, business rules that aren’t expressible as dbt metadata. |
| Reversibility | Same as any dbt change — revert the PR. | Delete or edit the entry in lightdash.project_context.yml. |
Privacy and data handling
- Issues runs against agent turns inside your organization only.
- Issues and findings are stored in Lightdash alongside your other agent data and respect your existing project and admin permissions.
- Disabling the toggle stops new AI scanning immediately; it does not delete previously collected issues.
Related
- Evaluations — run a fixed set of prompts against your agent and grade the answers.
- AI writeback — let an agent open a dbt pull request from chat.
- Autopilot — scheduled agent that cleans up content and flags issues for review.