Bootstrapping Your Knowledge Base from Existing Documentation

The most common reason teams delay adopting SentinelFlux isn't the pipeline or the agents — it's the blank-page problem. Writing a knowledge base from scratch feels like a significant upfront investment, especially for products that already have working documentation.

The Extract from Document feature removes that barrier. Upload a Word document, a PDF spec, or a Markdown file, and SentinelFlux splits it into the four standard KB YAML files — with a per-file preview so you can review and correct before anything is saved.

What it extracts and where it puts it

The AI reads your document and maps content to the four KB file types:

• application.yaml — product overview, modules, testing domains, and high-level business rules extracted from introductory sections and scope statements
• ui_pages.yaml — page-by-page descriptions including field names, validation rules, and expected behaviours pulled from UI spec sections and mockup annotations
• api_specs.yaml — endpoint definitions, request/response shapes, and status codes from API documentation sections
• product_knowledge.yaml — non-functional requirements, compliance notes, and domain glossary terms from non-UI sections

Files the AI can't find content for simply appear empty with a note — you're not required to save every file.

The review step matters

Each extracted file appears as a card with an editable YAML textarea and badges indicating issues:

• Error badges — required fields are missing (the file's save checkbox is automatically unchecked; you need to fix the errors before saving)
• Warning badges — recommended fields are absent but the file is valid and can be saved as-is

Don't skip the review. The AI extracts faithfully from what's written, but documentation often has implicit knowledge that never made it into the spec — the login flow that assumes session state, the validation rule that "everyone knows" but nobody wrote down. Read each file the same way you'd review a generated test script: trust but verify.

What it handles well and what it doesn't

Documents with clear structure — numbered sections, explicit field lists, table-based API specs — produce the cleanest output. The extraction quality roughly matches the document quality. Some patterns to watch for:

It handles well:

• Feature specs written as acceptance criteria ("the system shall…")
• API documentation with method, path, and response codes per endpoint
• Test plans with step-by-step scenarios and expected results
• Confluence exports (Word format) with heading hierarchy preserved

It won't extract reliably:

• Information embedded in screenshots or diagrams (text only)
• Implicit business rules mentioned only in meeting notes or comments
• Selector-level UI details (don't put these in the KB anyway — AppExplorer finds them)
• Version history sections or document metadata

A practical workflow

Here's how to go from existing documentation to a first test run efficiently:

1. Upload your most comprehensive spec — the one that a new team member would read to understand the product. Usually a functional spec, test plan, or user guide.
2. Review application.yaml first — get the modules and domains right before looking at the other files. The generation pipeline uses this as its index.
3. Skim ui_pages.yaml for field completeness — error states and validation rules are the most commonly missing pieces. Add them inline in the textarea before saving.
4. Save the files you're confident in; skip the rest — you can re-run extraction or add files manually later. Don't save a file full of errors just because it was extracted.
5. Run a small generation job immediately — pick one domain and trigger the pipeline. The generated test docs are the fastest feedback on whether your KB is specific enough.

Using it for incremental updates

Extraction isn't just for initial setup. When your team writes a new feature spec, run it through extraction to get an increment YAML for the KB. Review the diff, drop it in the Increments tab, and trigger the pipeline for the affected domain. The whole cycle from spec to new test cases can happen in a single afternoon.

The KB you build this way won't be perfect on day one — no KB is. But it will be dramatically better than starting from a blank file, and it will improve iteratively as the generated tests reveal what the AI did and didn't understand about your application.