> ## Documentation Index > Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt > Use this file to discover all available pages before exploring further. # Principles > The non-negotiables that shape every workflow in Brain # Principles These are the rules Brain follows in every workflow. They're not suggestions and they don't get traded off for speed. If a feature can't satisfy them, the feature changes. ## 1. AI drafts. Humans approve. The system commits. Every workflow follows the same spine. The AI prepares a first draft using whatever sources it has access to (emails, attachments, tech packs, CutMake records). The human reviews, edits, and explicitly approves. Only after approval does the system write to a production database or send a client email. This is non-negotiable for: * Creating new client records in CutMake * Confirming duplicate detection where the match is uncertain * Sending any email to a client * Finalizing a quotation * Moving a workflow into a completed stage * Any action that affects commercial communication Lower-risk drafts (BOM drafts, true cost drafts) may be written into the database as clearly-labeled AI drafts, editable in CutMake, but never marked final without human approval. ## 2. Scoped chat only. No general LLM. Brain doesn't expose "ask me anything." Every entry point routes to a registered workflow, skill, or query template. If a user asks something outside scope, the assistant responds politely: > "I can't help with that here. I can help you with RFQ processing, style creation, > BOM drafting, true cost, quotation, or pipeline tracking." This is a trust decision, not a capability decision. The underlying LLM can answer many things. Brain shouldn't, because the moment it tries and gets something wrong, trust in the workflows that matter erodes. **"Scoped" does not mean "slash commands only."** Natural-language chat is the default entry point. The [aggregator agent](/brain/staging/architecture/aggregator-and-workflows) enforces scope by only routing to registered workflows — anything else returns the polite redirect message. Free-form chat works because the destination is constrained, not because the input is restricted. Slash commands (`/create-style`, `/generate-bom`) exist as a power-user bypass for faster, more deterministic invocation. Both paths run the same workflows; the difference is whether the aggregator classifies intent first. ## 3. CutMake is the structured source of truth. CutMake and its Supabase database remain the canonical record for clients, styles, BOMs, true costs, quotations, materials, suppliers, and orders. Brain reads from CutMake for context. Brain writes its own working state (drafts, tasks, approval queue, correction logs) to its own database. When a draft is approved, it's promoted into CutMake through the normal write path. Brain doesn't fork CutMake's schema. It doesn't hold a parallel set of "production records." If you need the truth about a client, ask CutMake. ## 4. Every AI output is auditable. Every claim Brain makes traces back to a source: the original email, an attachment, a tech pack, a POM file, a measurement sheet, a quotation PDF, a CutMake record, an internal task, or a historical negotiation thread. The user can click and verify. This matters most for the manager use case. When Zean asks "what's happening with Jaspal style J26WGW153?", every milestone, every blocker, every recommendation must link to the artifact it came from. No unsupported assertions. ## 5. AI learns from corrections. Every time a merchandiser edits an AI-generated draft, the system records: * The AI's first draft * The human's final version * What field changed * What kind of change it was (correction, addition, deletion, recategorization) * Optional reason This correction log is the feedback loop. It's how we measure quality, find weaknesses, and improve the prompts, templates, and tools that drive the drafts. Common correction types we expect to see: * Missing BOM items * Wrong garment category * Incorrect button count * Wrong fabric interpretation * Missing hidden trims * Incorrect client PIC * Wrong style reference * Duplicate style confusion If a correction type recurs, that's a signal to fix the underlying skill or template, not to scold the merchandiser. ## 6. Permissions before action. Before any workflow that creates or modifies a record, Brain checks: who is asking, and do they have permission for this action? If they don't, Brain prepares the draft and routes the approval to someone who does (typically a manager). Roles are documented in [Roles](/brain/staging/roles/index). ## 7. Observability and changelog from day one. Every workflow that ships has: * **Tracing** through the chosen observability tool, so every LLM call, tool call, and decision is inspectable. * **Correction logging** in the application database, so we measure drift and improve prompts. * **A changelog entry** in this documentation, so the team and stakeholders know what shipped and when. A workflow without these three doesn't ship. We don't add them later. The discipline is what makes the iterative approach work over a year, not just a month. ## 8. Iterative, real-data, real-users from day one. No mock data. No fake customers. Every workflow is tested against real RFQs from Jaspal, Lulus, ASOS, and the rest of our actual client base. Mai and Zean are the day-one users; we don't scale to additional merchandisers until those two are using Brain daily and finding it faster than their current workflow. The correction loop is dead without real data. The trust signal is dead without real users. Both have to be live from the first feature.