Introducing Copilot Knowledge Base for Flux Engineers

Today, EE teams using Flux are already leveraging Knowledge Base to encode their professional know-how—things like project constraints, personal style guides, and industry-vetted best practices—directly into Copilot. In this post, we’ll show you exactly how to unlock that power for yourself: from writing rock-solid triggers to scoping entries at the project, user, and system levels.

Don’t miss out on this opportunity. Take these tips and tricks, apply them today, and watch Copilot transform from a tool into a teammate who thinks—and designs—just like you.

With Knowledge Base, we capture insights at three levels:

• Project-level: Requirements, calculations, and architecture choices unique to your current board
• User-level: Your personal style guides, part-family preferences, and schematic conventions
• System-level: Flux-curated best practices and EE-expert recommendations that benefit everyone

Let’s dive into how it works, why it matters, and—most importantly—how you can craft entries that make Copilot truly think like you.

1. How the Knowledge Base Works & Why It Matters

Flux Copilot’s Knowledge Base entries can be thought of at four levels—from narrow rules to high-level mindsets. When you prompt Copilot, it performs a semantic search, a search that uses sentence structure similarity to find matches , then weaves the most relevant guidance into its reasoning.

Semantic Triggers

Every entry begins with a “use when” phrase. Copilot uses vector search, finding similar items in a dataset by comparing their numerical vector representations (embeddings) instead of relying on exact keyword matches, to match your prompt to the right piece of advice based on semantic similarity.

Context Injection

When you ask Copilot, for example, to generate a buck-converter schematic, it retrieves relevant entries—your project’s input-voltage constraint, your favorite inductor series, or a net-naming rule—and seamlessly injects that context into its response.

Three-Tier Scope

• Project: Active only within the board you’re editing
• User: Applies across all your Flux projects
• System: Flux-approved, peer-reviewed EE best practices

Impact & Examples of Good Results

2. Crafting Effective “Use When” Statements

The “use when” is the most critical piece of any entry—it tells Copilot when to apply your guidance, based on semantic similarity, not just keywords. If this is off, your advice will never—or always—fire.

• Keep it short (6–9 words)
• Lead with your key concept (noun or verb first)
• Be 100% true to the context you’re capturing
• Use action verbs (e.g. designing, validating, calculating)
• Broad vs. Specific:
• • Broad: use when: filtering power rails
  • Specific: use when: designing Pi filters for multi stage power rail

Pro Tip: After Copilot suggests a “use when,” refine it immediately. A small tweak—“for high-speed analog filters” instead of just “for filters”—can mean perfect recall instead of irrelevant noise.

3. Project-Level Knowledge (with Examples)

Project-level entries store all the details that make your current board design one-of-a-kind. They include specific requirements (like voltage tolerances), physical or thermal constraints, chosen topology decisions, and any reference calculations you’ve performed. By capturing the reasoning behind each architectural choice, Copilot can apply context-aware guidance tailored solely to this project. This prevents generic suggestions from slipping through and keeps your design aligned with its unique specifications.

• Design requirements
  Example:

use when: selecting temperature sensitive components
content: this design is exposed to temperatures of -10 F to 110 F on a Northeastern US State yearly temperature cycle.

• Design constraints
  Example:

use when: board size constraints
content: Ensure components selected are optimized for a wearable device sized board.

• Architecture decisions
  Example:

use when: designing a power distribution network
content: Optimize for small size and effeciency for each power component.

4. User-Level Knowledge (with Examples)

User-level entries capture your personal design preferences, workflows, and preferred subcircuit patterns so that Copilot reflects how you work. They let you encode procedural steps—like your favorite LDO selection or filter-design process—directly into Copilot’s memory. With these entries, Copilot adopts your schematic conventions, part choices, and step-by-step habits, producing outputs that feel tailored and familiar. In effect, it transforms Copilot from a generic assistant into one that thinks and advises just as you would.

• Procedural instructions
  LDO selection

use when: LDO selection process
content: When selecting an LDO, follow a structured four-step workflow: screen basic parameters, filter performance (PSRR, noise), prioritize the key metric, and check optional features.

• Filter design

use when: filter design process
content: When formalizing filter design, begin with clear specs (ripple, f_c, f_s, attenuation) and then proceed with topology selection, component choice, simulation, and disciplined prototyping.

• Schematic style guidelines
  Example 1:

use when: naming nets for differential pairs  
content: Prefix with SIG_DP_ or SIG_DM_ and suffix with _N/_P for polarity clarity.  

• Example 2:

use when: naming nets with series resistors
content: Add a suffix _R to the name of the incoming net to the resistor and use it for the outgoing net name.  

• Tips for specialized circuits
  Example:

use when: designing op-amp instrumentation amplifiers  
content: Add 10 Ω series resistors on each input to decouple source capacitance.  

• Component-specific instructions
  Example:

use when: using TI SN65HVD230 CAN transceiver  
content: Place 120 Ω termination resistors close to the transceiver and add 0.1 µF decoupling on VCC.

5. System-Level Knowledge (How We Build It)

Our EE team crafts system entries with the highest rigor—so every user benefits from vetted best practices.

1. Source & Draft‍
   
   • Extracted from whitepapers, application notes, and our expert’s experience‍
2. Peer Review‍
   
   • Our team of senior engineers validate technical accuracy and remove any vendor bias‍
     
3. Semantic Validation‍
   
   • We test “use when” triggers against hundreds of prompt variations to ensure relevance

Note: Every word is chosen deliberately—“use when” must be as true as the “content” it triggers.

6. Managing Your Knowledge Base

As your KB grows, keep it relevant and helpful by:

1. Watching Scopes‍
   
   • ✅ Don’t mix project-specific facts into user-level entries‍
   • Edit user entries: Profile → Knowledge → User Knowledge‍
   • Edit project entries: Project → Knowledge → Project Knowledge‍
2. Monitoring Performance‍
   
   • Hit the 👎 thumbs-down when Copilot misapplies an entry or forms a bad response
   • Identify entries causing loops: “Why does it always suggest the same value for an inductor?”‍
3. Signs of Harmful Entries
   
   • Over-fixation: Copilot insists on one solution for every design‍
   • Inaccuracies: Obvious part-selection errors or illogical guidance‍
4. Regular Audits‍
   
   • Periodically review and prune outdated or narrow entries
   • Elevate broadly useful user entries to system level for team-wide benefit

Start Building Your KB Today

Adding your knowledge to Copilot doesn’t just make it smarter—it makes you faster, more consistent, and more confident. Open Flux Copilot, watch for that “Knowledge Suggestion” button in the response, and begin teaching your AI teammate how you design. Over time, your Knowledge Base becomes a living encyclopedia of your best practices—project by project, decision by decision.