Getting started

Fabric Atlas is a governed knowledge base and reading portal for Microsoft Fabric. Approved sources become atomic, cited claims; an admin verifies every claim before anything is built on it; verified claims power topic content, solution designs, and lessons — and every generated piece is validated against what it cites.

The pages

• Home — the big picture: a capability map you can filter, live claim counts, recently published content, and Advisor prompt shortcuts.
• Topics — the reading portal: a topic tree where each topic gathers the articles, designs, and lessons written about it. Start here if you want to learn Fabric.
• Blogs (under the Knowledge menu) — every article, design, and lesson in one filterable, chronological list (filter by kind or topic), and the detail page for each.
• Reference Docs (under the Knowledge menu) — authoritative deep-dive technical whitepapers and engine internals reference documentation with interactive traces and SVGs.
• Capability Registry — the spine: every tracked capability with its live claim, depth, and diagram coverage. Read-only — a coverage dashboard, not a moderation tool.
• Sources — every approved source with its trust tier, searchable and filterable by tier.
• Learn — lessons grouped into Beginner, Intermediate, and Expert tiers.
• Roadmap — what's coming to Microsoft Fabric, tracked against the capability registry.
• Advisor — ask a question and get an answer grounded only in verified claims.
• Search (under the Build menu) — one search box across topics, content, claims, and sources.
• Author (under the Build menu) — how the local, git-tracked authoring workflow works, for contributors.
• Help — these pages.
• Favorites and Settings — Favorites is for any signed-in user; Settings is admin-only (see Admin settings).

The trust model in one screen

1. Nothing enters the knowledge base without a source and a trust tier (T1 Microsoft Learn … T6 unknown).
2. Every extracted claim starts pending and needs an admin to verify it before it can be cited.
3. Articles, designs, and lessons may only cite verified sources, and every factual sentence carries an [Sn] citation you can trace back to its source.
4. Publishing never overwrites content in place — every publish of an article, design, or lesson creates a new version, and the previous version is archived, not lost.
5. If you spot something wrong, every article, design, and lesson has a Report an issue button — no sign-in required.

Nothing in this portal is invented by a model and left unchecked — that is the point.

Submitting sources

Queuing a new source for ingestion is an admin action, done from Settings → Queue: paste a URL, pick a trust tier, and optionally add tags and a note for the curator. Queuing does not ingest anything by itself — it adds the URL to the ingestion queue for a local knowledge-curator agent to pick up.

Trust tiers

Lower numbers are more trusted. Pick honestly — the tier travels with every claim the source produces and shows on every citation and on the Sources page.

The queue lifecycle

Queued URLs appear in the Settings → Queue table with one of these statuses:

• queued — waiting for an ingestion run.
• claimed — reserved by an operator or ingestion run. This does not create knowledge claims; the similar names describe different things.
• ingested — done; the published source and its pending claims are now in the knowledge base, and the queue item links to that source.
• failed — something went wrong (the note explains what); requeue puts it back in line, dismiss drops it.

After it's queued — what happens next

1. Ingest — a contributor opens the repo in Claude Code or Codex and runs /ingest-batch. The knowledge-curator agent claims each queued item, reads the source, and extracts a handful of paraphrased claims tagged to a capability and depth — never copied text, and external images are linked with attribution, never re-hosted. The source file is ready for review. Reserving the queue item alone does not perform this step.
2. Publish and link — publish the file with Settings → Publish → Source (+ claims). This creates or refreshes the source and inserts its extracted claims as pending. Then complete the queue item by choosing the resulting source; its status becomes ingested.
3. Verify — the new claims arrive as pending. An admin approves them in Settings → Claims, one at a time or with Verify all for a whole capability at once. Until a claim is verified, no article, design, or lesson can cite it.
4. Reuse the knowledge — once verified, the claims are available to the blog-author, solution-architect, and learning-author agents. Running /blog, /design, or /lesson drafts cited content from the new knowledge. /blog creates an article when the topic has no article, or augments the active article only when the source adds verified coverage, depth, diagrams, or drift corrections. /design authors both scenario-specific solution architectures and reusable data architecture patterns; tag reusable patterns DataArchitecture and ArchitecturePattern. Publish the resulting file through Settings.
5. Commit — ingestion wrote content/sources/<slug>.json; commit it to git so the knowledge is reproducible on any environment.

If an item is marked failed, the note explains why (usually an unreachable URL); requeue tries again, dismiss drops it.

Curation loop

Claim moderation happens in Settings → Claims, and is admin-only. The public Capability Registry page shows the same coverage as a read-only dashboard — verified counts, depth coverage, gaps — but has no moderation controls of its own.

Claim states

• pending — freshly extracted, awaiting review.
• verified — approved; it can now ground articles, designs, and lessons.
• rejected — dismissed (wrong, irrelevant, or unverifiable).
• duplicate — near-identical to an active claim from another source; needs a decision before it can be cited.
• superseded — replaced by a newer version of the same claim; kept as history.

Working the queue

The Claims table in Settings filters by status (pending / verified / duplicate / rejected / superseded / all). Each row has row-level actions:

• Verify — approves a pending claim.
• Reject — dismisses it (or, for a duplicate row, dismisses the duplicate — the button reads Reject either way).
• Promote — only shown on duplicate rows; sends the claim back into the normal pending/verify flow because it turned out to be genuinely new information.
• Supersede — opens a dialog to edit the claim text. This does not edit the claim in place: it creates a new pending claim version and deactivates the current one.

When a whole capability has a backlog of pending claims, the Verify all pending in… control at the top of the panel verifies every pending claim for one chosen capability in a single action.

Audit log

Settings → Logs shows a combined activity stream: admin actions (source review, topic edits, publishes) and the claim-status log (previous status → new status, with a text snippet) in one filterable, searchable list. Every claim status change is recorded here.

Topics and content

Topics is the reading portal. Topics form a nested tree (areas → topics → sub-topics, any depth). Each topic can be linked to one or more capabilities in the Capability Registry, and each topic gathers whatever content — articles, designs, and lessons — has been written about it.

The topic tree

A collapsible tree sits on the left of the Topics page, a topic's own page, and every content detail page. It starts as a narrow icon rail; hover it (or click the pin icon) to expand it into the full topic hierarchy. When you're viewing a topic or a piece of content, the tree auto-expands the chain of ancestor topics down to the one you're on, so you always know where you are.

The main Topics page also shows top-level areas as cards, each listing its sub-topics with a short description — a faster way to scan the whole map before drilling in.

A topic page

Open any topic to see its description, the capabilities it's mapped to (each is a link into the Capability Registry), a Content section, and its subtopics.

The Content section lists everything published about this topic — articles, designs, and lessons together, each tagged with a kind pill (Article / Design / Lesson) so you can tell them apart at a glance. Click any row to open it.

Reading a piece of content

Every article, design, and lesson opens at /content/<kind>/<slug> — the same surrounding layout regardless of kind, with the topic tree on the left, a table of contents in the middle-left rail, and the citation list on the right.

• The kind pill at the top tells you whether you're reading an article, design, or lesson.
• Reading time, number of sources, and (if any are embedded) number of diagrams are shown under the title.
• A preview badge appears if the content touches a capability that is still in preview.
• Every factual sentence carries an [Sn] chip — hover it for the source title and tier, and see the citation list on the right for the full legend.

Sections only exist where verified claims support them — a topic with no performance claims simply has no performance section in its article, by design.

The opening block right under the title varies a little by kind, when the piece has the relevant detail filled in to show:

• Designs may show a Scenario summary and a Constraints list right up top, before the write-up itself — the situation the design was built for and the limits it was designed around.
• Lessons show their level (Beginner / Intermediate / Expert), an estimated time to work through them, and a What you'll learn list of objectives, plus Prerequisites where the lesson names any.
• Tutorial-style articles may show a Before you start list and an Outcome summary the same way.

If a piece doesn't have that detail filled in, this block simply doesn't appear — you go straight from the title into the write-up, same as always.

Step-by-step walkthroughs

Some articles and tutorials — the ones that walk you through actually doing something, not just explaining a concept — present part of the text as a numbered sequence of connected step cards instead of plain paragraphs, so you can see at a glance how many steps there are and where you are in them.

If you like, you can click the circle on a step to check it off as done; it turns into a checkmark. For anonymous visitors, progress is remembered in your browser only. Signed-in users get server-side progress sync — your progress follows you across devices.

A walkthrough is often followed by a Checkpoint callout describing what you should see if you followed the steps correctly, so you can confirm you're on track before moving on.

Callouts

Beyond the checkpoint mentioned above, articles, designs, and lessons use a small set of other labeled callout boxes: Note, Tip, Warning, Important, Before you start, Expected result, Key takeaway, and Definition. One more — Inference (not a sourced fact) — is the visible marker for the rule that generated text must label its own inferences: anything in that box is the author's reasoning from the cited claims, not a claim with its own citation. Some content also includes a Try it box that stays collapsed until you click it to reveal a worked answer or example.

Interactive diagrams

Diagrams embedded in content aren't static pictures. Click or tap a region — a box, a component, a step in the flow — to open a detail panel with a plain-language explanation of that part, the evidence and citations behind it, and, where the diagram has it, a worked example, the controls that affect it, and what happens when it fails. Hovering a region (or moving keyboard focus to it) shows a quick preview tooltip even without clicking.

Open a diagram in its zoom view (the button in its corner) to pan and zoom freely, and — when the diagram offers one — start a guided walkthrough that steps through its parts in order with Next/Previous controls, highlighting one region at a time instead of leaving you to find your own way around. Some diagrams also let you filter which layers are shown, or jump straight to a related diagram, topic, capability, or piece of content from inside the detail panel.

Lessons: objectives, time, and completion

Every lesson states its level, an estimated time to work through it, and what you'll be able to do afterward (its objectives, and sometimes prerequisites) — shown at the top of the lesson, and again as a short summary on its card on the Learn page. A Mark complete button on the lesson lets you check it off; completed lessons then show a checkmark on their Learn page card too. For anonymous visitors, progress is remembered in your browser only. Signed-in users get server-side progress sync — your progress follows you across devices.

Reporting an issue

Every piece of content has a Report an issue button, plus a small feedback dot next to each section heading (shown on hover, or always visible on touch) so you can flag a specific section instead of the whole piece. Pick a category — factual error, outdated, unclear, broken link/diagram, or missing citation — and describe what's wrong; quoting the exact sentence helps. You do not need to be signed in to report an issue.

A report never edits the content directly. It's reviewed — with agent assistance that checks the report against the article's actual text and citations before a human acts on it — and, when it's actionable, routed into the normal ingestion/curation pipeline like any other editorial work.

Versions

Publishing an article, design, or lesson always creates a new version — it never overwrites the previous one in place. When an admin republishes a slug from Settings → Publish, the prior active version is archived (its slug becomes <slug>@v<N> and its status changes to superseded) and the new version becomes active. This applies to all three kinds equally.

Adding or changing topics

• The seed file — content/topics.json in the repo is the authoring source of truth for bootstrapping a fresh environment. Add a node with a unique slug, a name, an optional description, and optionally a parent_slug (any nesting depth) and sort_order.
• Settings → Content → Topics is where an admin edits a topic live: name, description, parent (re-parenting), sort order, active flag, and tags. This is a metadata edit, not a knowledge change, so it applies immediately — unlike claims and content, topics can be edited in place. If a live edit should survive a fresh environment, mirror it back into content/topics.json.

A topic's link to capabilities is what makes its claims and coverage numbers show up — a topic with no mapped capabilities has no claims to draw on, even if its slug is spelled correctly everywhere.

Generating content for a topic

Articles, designs, and lessons are authored by agents in the IDE, never by the server:

• /blog <topic-slug> — the blog-author reads the topic's verified claims and writes a cited article to content/articles/<slug>.json.
• /design <scenario> — the solution-architect drafts a cited design to content/designs/<slug>.md, expected to set a topic_slug so it shows up on the right topic page (older designs published before this existed may show as Uncategorized until an admin re-links them).
• /lesson <capability-id> <level> — the learning-author writes a tiered lesson to content/lessons/<capability>-<level>.json.
• /publish-topic <topic-slug> — the full chain for a topic starting cold: a coverage check, a stop for human claim verification, at least two original diagrams, the article, and validation.

If a topic has too few verified claims, these agents refuse and report the gap instead of writing filler — queue more sources for it (see Submitting sources), verify them, and run the command again. Whatever the agent writes still has to be pasted into Settings → Publish by an admin before it goes live; that step is what actually creates the new version.

Search

The Search page searches the whole knowledge base from one box. Type a query and press Search (or Enter) — results are grouped into:

• Topics — names and descriptions in the topic tree.
• Content — articles, designs, and lessons together: any piece of content whose title, summary, or body matches, with a kind badge on each result.
• Claims — the atomic facts themselves, each shown with its depth, capability, and source link.
• Sources — titles and reader summaries of approved sources.

Each group shows its match count. Clicking a topic opens the topic page; clicking a content result opens that article, design, or lesson; clicking a claim's source link or a source result opens the source URL in a new tab.

What search reflects

Search only returns published, active content and active sources and topics — superseded versions and archived content never appear. Search does not currently support filtering by kind or by tag from the results page; it is a single combined query across topics, content, claims, and sources.

Validation and trust

Fabric Atlas's core promise: no fabricated content. This page explains the machinery behind that promise.

Citations

Every factual sentence in an article, design, or lesson carries an [Sn] citation that resolves to a real, approved source with a trust tier. The citation legend for a piece of content lists every cited source with its title and tier. Publishing refuses outright if a document has no cited sources at all, or if a cited source slug can't be resolved on the server — there is no way to publish an uncited document.

The validation pass

Two kinds of checking happen, at different points:

1. Deterministic checks (server-side, on demand): from Settings → Content, an admin can run Validate on an article or design. This checks that the document has at least one cited source, and that every diagram image embedded in its body is a diagram actually registered in the system — a missing diagram file is a critical finding. The result sets a confidence score and a ready to share flag (true only when there are zero critical findings).
2. Agent review (in the IDE, before publishing): the validation-reviewer agent reads a drafted article or design and reasons about grounding (does each statement follow from a cited claim?), coverage (is something the scenario needs missing?), and antipattern issues (known Fabric bad practices, and copied-rather-than-paraphrased text). This runs locally as part of the authoring workflow, before the file is ever pasted into Settings → Publish.

Trust tiers

Every source carries a tier from T1 (Microsoft Learn) to T6 (unknown), shown on source cards and in every citation. Tiers don't block content from being published — they make the strength of the underlying evidence visible wherever it is used.

What the system never does

• Invent product limits, quotas, or roadmap claims.
• Publish an article, design, or lesson with no cited sources.
• Re-host external images (they are linked with attribution; diagrams are original SVGs authored by the diagram-author agent).
• Overwrite a published article, design, or lesson in place — every publish is a new version; the previous one is archived, never lost.

Agent workflows

Fabric Atlas is local-first. Claude Code and Codex run in the IDE, read approved sources, and write structured results to content/. The server stores and validates those results; it does not invent claims.

Queue and watcher configuration is private workflow state. Local agents read a sanitized snapshot from GET /api/public/hooks/poll-feeds using FABRIC_ATLAS_APP_URL and the server-only FABRIC_ATLAS_AGENT_READ_TOKEN. If either value is missing or rejected, orchestration stops with an explicit configuration error; an inaccessible queue is never interpreted as an empty queue.

Claude Code

Claude workflows live in two places:

• .claude/agents/ contains focused agents such as knowledge-curator, blog-author, content-orchestrator, validation-reviewer, diagram-author, feedback-triage, and docs-author.
• .claude/commands/ contains slash commands that call those agents, including /ingest, /orchestrate-content, /blog, /publish-topic, /validate, /drift, /lesson, /commission-diagrams, /gaps, /triage-feedback, and /docs-sync.

Start with /orchestrate-content when you want a master view across unclaimed queue items, claimed work, pending claims, RSS poll state, existing articles, local drafts, and diagram gaps. It returns a ranked workplan and stops at human gates such as Settings → RSS Feeds, Publish, Queue, and Claims. Article candidates are self-evaluated for grounding, novelty, richness, depth, diagram coverage, and whether the next human gate is clear.

Use /triage-feedback to review new reader-submitted "Report an issue" notes (see Admin settings → Feedback): the agent checks each report against the article's actual text and citations and writes a verdict file for an admin to apply in Settings.

Use /gaps for the derived ## Internals coverage-gap inventory (never a hand-written gap document) — it ranks placeholders by architectural impact and routes each to a source, a queue line, or a depth to deepen.

Use /docs-sync after changing routes, settings, source submission, curation, validation, or authoring workflows. The docs-author agent reads the real code and rewrites only Help pages that drifted.

Codex

Codex prompt templates live in .codex/prompts/. Install them once by following .codex/README.md, then use:

• /prompts:fa-orchestrate to rank queue, RSS, claim, article, and diagram work.
• /prompts:fa-ingest to turn an approved source into paraphrased, cited claims.
• /prompts:fa-blog to draft or enrich a cited topic article from verified claims.
• /prompts:fa-design to draft a cited architecture design from verified claims.
• /prompts:fa-diagram to author original diagram assets.
• /prompts:fa-validate to run a validation-review pass.
• /prompts:fa-drift to compare a changed source with existing claims.
• /prompts:fa-lesson to create a tiered learning draft.
• /prompts:fa-gaps to generate and route the ## Internals coverage-gap inventory.
• /prompts:fa-docs-sync to refresh the Help section from the actual code.

Reader feedback triage (/triage-feedback) does not yet have a Codex prompt equivalent — run it from Claude Code.

Use FOCUS=<topic-or-capability> with /prompts:fa-orchestrate when you want a narrower plan, for example /prompts:fa-orchestrate FOCUS=ai-apis.

After verifying claims from a newly published source:

• run /prompts:fa-blog TOPIC=<topic-slug> to create a missing article or augment an existing article when the source adds new verified coverage, depth, diagrams, or drift corrections;
• run /prompts:fa-design SCENARIO="<workload problem>" for a solution architecture;
• run /prompts:fa-design SCENARIO="Reusable <pattern> data architecture pattern" when a reusable data architecture pattern is missing, and tag it DataArchitecture and ArchitecturePattern.

Solution architectures and reusable data architecture patterns both use the governed Design content type today. Publish them through Settings → Publish → Design, then validate before sharing.

To run the whole journey as one resumable job, use /prompts:fa-orchestrate EXECUTE=true (Claude: /orchestrate-content execute). The orchestrator:

1. drains open source queue items and writes the extracted source files;
2. compares the new evidence with existing articles, designs, and diagrams;
3. asks one compact question round about proposed article creation/augmentation, solution scenarios, and missing reusable data architecture patterns;
4. pauses while an admin publishes the sources, completes the queue items, and verifies their pending claims;
5. resumes to author and validate every selected artifact; and
6. finishes with one dependency-ordered Settings → Publish → Publish all release action.

The mid-run source/claim checkpoint is mandatory: newly extracted claims cannot ground an article or architecture until they have been published and human-verified.

For latest RSS coverage, poll feeds in Settings first, then rerun the orchestrator. The agents read the resulting queue; they do not poll feeds or complete queue items themselves.

Article and lesson ideas are generated inside the app itself (Settings → Pipeline → Article Ideas), not by a local agent — see Admin settings. Approving an idea there surfaces a ready-to- copy /blog, /lesson, or Codex-equivalent command with an --idea <id> flag that folds the idea's brief into that authoring run automatically.

Documentation rules

Documentation follows the same discipline as claims:

• Do not describe features that do not exist in the current code.
• Keep Help pages user-facing; implementation details belong in docs/.
• When docs change, update content/help/ and publish or seed the content so the Help page in the site reflects the files.
• Admin Settings can edit Help metadata and body text, but git-tracked content/help/ remains the source to commit. Mirror DB edits back to files before considering documentation current.
• If a UI workflow changes, run the documentation generator before sharing the change.

Admin settings

The Settings area is visible only to approved admins (the nav's Settings link only appears once a signed-in user's admin role is confirmed). Its tabs are grouped into People, Knowledge, Published, Pipeline, and System.

Users

Invite a user by email and starting role. Newly signed-up users appear with a status badge; the checkmark action approves them (a user must be approved before they can use any authenticated area). Editor and Admin buttons set roles; the X button suspends a user. Pending invitations are listed separately and can be revoked or expired from there.

Content

Edits metadata for Sources, Topics, Capabilities, Help docs, and Diagrams, plus lists (read-only summary, linking to their own workflows) for Designs. Each list's Edit button opens a dialog for that item's metadata fields (title, summary, description, tags, etc.) — this is a direct, in-place edit, appropriate because it's metadata, not knowledge.

• Source rows have a Review action that queues the source for a drift/re-ingest pass — it lands back in the Queue tab.
• Design rows have a Validate action (see Validation and trust) but their body text is still authored in content/designs/ and republished, not edited here.

Claim text is never edited from the Content tab — that happens in Claims.

Claims

The full claim moderation workbench: filter by status, Verify/Reject/Promote individual claims, Supersede to create a new pending version of a claim's text, and Verify all pending in… to batch-verify every pending claim in one capability. See Curation loop for the full behavior.

Articles

A table of published articles with Validate (runs the deterministic checks and updates the confidence/ready-to-share flag) and Edit as new version (opens a dialog to change title, summary, body, and cited sources; saving creates a new published version — it never mutates the existing row). A version cannot be saved without at least one cited source.

Diagrams

Lists registered diagrams with an Edit action for caption/kind/topic metadata, and lets an admin commission additional diagrams for a topic at a chosen future time — this adds an item to the same queue mechanism the ingestion queue uses, tagged for diagram work. A laptop agent later drains due commissions with /commission-diagrams.

Feedback

Every reader-submitted "Report an issue" note lands here, newest first, with its category (factual error, outdated, unclear, broken link/diagram, missing citation), the section it was attached to, and its status (new / triaged / actioned / dismissed). Reports on the same article and section are grouped with a count so a repeated complaint stands out.

Feedback is triaged locally, not on the server: run the /triage-feedback command, which checks each new report against the article's actual text and citations and writes a structured verdict file. Paste that file's contents into Apply triage results here to post each verdict's status and AI analysis back to the matching row. Once triaged, a row can be marked actioned (if it fed into a fix) or dismissed.

Pipeline → Overview

A single dashboard of the whole discover-to-publish journey: active watchers, open/failed/ ingested queue work, published sources, claims awaiting verification vs. verified, and live articles — each stage tile jumps straight to its own tab. Below it, the full operator sequence (reserve → extract locally → publish and link → verify) and shortcuts to run the blog/design prompts on newly verified knowledge. A Needs attention list surfaces failing watchers, failed queue items, and a pending-claims backlog, and a Suggested next actions list ranks concrete next steps with a copyable command for each.

Pipeline → Article Ideas

Generated candidate ideas for new articles or lessons, fused from the Fabric roadmap, coverage gaps, reader feedback, and stale articles. Auto-generate produces ideas from all of those signals at once; Generate from prompt takes an admin-supplied topic or direction instead (still checked against real grounding before being kept). Each idea shows its signal type, target content kind (article or lesson), a rationale, and — once expanded — a ready-to-copy local command (/blog, /lesson, or their Codex equivalents) that a contributor runs to actually author it.

An idea can be approved (marks it claimed so a human can author it), amended (edit its title, target slug, angle, rationale, length, or diagram guidance before it's authored), or dismissed. A dismissed idea can be revived back to the queue and re-approved later. Once an idea has actually been authored, its brief is frozen.

Pipeline → Watchers

Add, test, pause, or delete watchers for RSS/Atom and JSON feeds, sitemaps, listing pages, or individual pages. Every watcher is always auto-mapped and must pass a server-side discovery test before it can be added. Polling tries the retained successful endpoint first, then falls back in order through feed, sitemap, listing, and single-page monitoring. The first strategy returning safe in-scope output becomes the retained mapping for the next poll; it is a performance hint, not a permanent lock. New URLs and meaningfully changed known sources land in the Queue for human-reviewed ingestion.

Test and detect previews the winning strategy, resolved endpoint, sample count, and every attempt made. A single page is valid output: its normalized content fingerprint is monitored and a review is queued only when it changes. Fetch/parse errors, empty results, and out-of-scope results fall through to the next strategy. If every strategy fails, creation is refused with structured diagnostics rather than saving a watcher that cannot currently be polled.

Some publishers challenge all datacenter traffic (Cloudflare and similar), so server-side polling of an otherwise-working feed fails permanently. For those watchers, a contributor runs node scripts/poll-watchers.mjs on their own machine: it uses the same retained-first fallback hierarchy with the same honest client identity, dedupes against the knowledge base and open queue, and appends new posts to content/queue.md for the usual review + /ingest-batch flow.

Pipeline → Queue

Queue a source URL submits a new URL with a trust tier, tags, and a note — this is the admin-side form described in Submitting sources. The table below lists every queue item with its status and per-row actions: reserve (stored as claimed), complete (needs a resulting source id), fail (needs a note), requeue, and dismiss. Checking multiple still-queued rows and clicking Reserve selected claims them all in one action instead of one row at a time.

Reserve does not extract the source or create claims. The complete sequence is shown in Pipeline → Overview: reserve → extract locally → publish Source (+ claims) → link the queue item to the result source → verify pending claims. The same overview then routes verified knowledge into a new or augmented article, a solution architecture, or a reusable data architecture pattern. Both architecture outputs are currently published as Design; pattern designs use the DataArchitecture and ArchitecturePattern tags.

Pipeline → Publish

Paste an agent-authored JSON file here to replay it into the knowledge base. Choose the kind — Source (+ claims), Article, Design, Lesson, or Diagram(s) / assets.json — and paste the corresponding content/*.json file. Re-publishing a source keeps its verified claims and only refreshes the pending ones. Publishing an article, design, or lesson always creates a new version; the previous version is archived, never overwritten. For an article with a new embedded diagram, publish the diagram(s) first so the article's embedded-diagram check passes.

Pipeline → Roadmap

Mirrors the public Microsoft Fabric roadmap (via a community mirror API) so upcoming capabilities can inform article ideas and coverage planning. Poll now syncs the latest items; each shows its status, release type, target release, and publish date, and can be mapped to a capability with a dropdown so its signal counts toward that capability's planning. Canonical Microsoft blog links found during the poll are queued as sources and auto-claimed, but their extracted claims still go through normal human verification like any other source.

Logs

A combined, filterable activity stream: admin actions (user approvals, role changes, topic and source edits, publishes) and the claim status log (previous → new status) together, searchable and filterable to one stream or the other.

System

Read-only KPI dashboard: platform stats plus a live breakdown of capability maturity (preview/GA/deprecated) and claim verification percentage, pulled from the same coverage data that powers the Capability Registry page.

System → Migrations

A read-only health check for the database schema: which checks pass, warn, or fail, the latest applied migration, and a list of recently applied migrations. Useful for confirming a deploy landed cleanly, not a place to run or author migrations.

Source of truth

content/ remains the canonical, git-tracked authoring format. Settings edits happen directly against the database; if a change should survive a fresh environment (a new topic, an edited Help page, a re-parented topic), mirror it back into the matching content/ file before considering it durable.