DRCY is AllSpice’s AI-powered design review intelligence layer, built to run consistent, auditable first-pass checks directly inside your hardware workflow .
For engineers, that means fewer late surprises, fewer repetitive checks, and more time spent on real design decisions. DRCY reviews your actual schematics and referenced datasheets, surfaces potential issues with traceable evidence, and leaves final judgment where it belongs: with you.
For engineering leaders and directors, DRCY establishes a reliable baseline for review quality across teams. It helps ensure essential checks happen early, when fixes are fast and inexpensive, and provides auditability inside the AllSpice system of record . Review coverage becomes systematic rather than dependent on individual bandwidth or memory.
DRCY is not a replacement for human expertise, and it is not positioned as exhaustive verification. It is a first-pass reviewer designed to strengthen decision-making, reduce risk, and improve consistency before sign-off .
The FAQs below address common questions about how DRCY works, how it handles data, what it checks today, and where its boundaries are. If you have additional questions, our team is happy to help.
If you are looking for something else, check out our General FAQ
What model is your AI using?
Today, AllSpice runs on Claude Sonnet through Amazon AWS Bedrock for Cloud and Enterprise deployments. Model choices may evolve as the ecosystem improves.
We selected Claude Sonnet because it consistently performs best in our internal testing for schematic and datasheet driven reasoning.
That said, AllSpice is not locked to a single model. The platform is designed to support multiple LLMs. Customers can configure their own model provider, including custom endpoints, tokens, and specifications. This is most common in self hosted environments today, but available more broadly as needed.
How do you train your models?
We do not train or fine tune AI models on customer data.
Instead, DRCY works by providing very specific, task focused context at review time. That context includes your schematic files, component data, and the relevant datasheets needed to evaluate connections and constraints.
The model reasons over your actual design inputs during the review, then discards that context after inference.
Your designs are not used to train shared models, and your IP does not leak into future outputs. You get AI reasoning grounded in your data, without giving up control of it.
Why does DRCY produce differing results run-to-run?
DRCY is designed to be consistent in what it checks, while allowing some variability in how findings are expressed.
Each run analyzes real schematic data and referenced datasheets using the same review framework, scoring, and guardrails. That ensures coverage is stable and repeatable.
Small differences can occur because AI models reason probabilistically, especially when interpreting complex or ambiguous design patterns. DRCY mitigates this by grounding every finding in concrete design evidence and prioritizing higher confidence issues.
Most importantly, DRCY is positioned as a first pass reviewer. Its role is to surface potential issues early, with logical reasoning and evidence.
You get consistent coverage and early signal, without relying on brittle, rule only checks or manually searching datasheets for the fourteenth time.
How is DRCY deployed in a self-hosted AllSpice instance?
In a self-hosted AllSpice deployment, DRCY runs entirely inside your environment.
Inference is performed using a customer configured LLM endpoint. No design data or inference traffic is sent to AllSpice managed infrastructure. You control where the model runs and how it is accessed.
For datasheets and part data, DRCY can connect to an internal part library, find and pull datasheets automatically from an online source, or use datasheets uploaded directly into the repository, consistent with other AllSpice workflows.
You gain AI assisted design review while keeping your infrastructure and clear data boundaries.
Can DRCY flag a component that is NRFND or end-of-life?
Also asked: Can we specify a temperature range and have DRCY verify the temperature range of all the parts?
Component lifecycle checks like obsolescence, end of life status, stock availability, and lead times are best handled through AllSpice Actions, not DRCY. Actions use deterministic rules and trusted supplier or internal databases to flag these risks with higher confidence and fewer false positives. AllSpice Actions can connect to any service with an API, such as Digikey, Mouser, Silicon Expert, Newark, etc.
DRCY focuses on interpretive design review using schematic and datasheet context, while Actions handle objective, data driven supply chain checks. We recommend adding extra review coverage with Actions for tasks like attribute checks. DRCY can find temperature escapes, but Actions can more quickly and more robustly check attributes.
You get clearer signals and more reliable automation by separating probabilistic AI analysis from deterministic operations like lifecycle checks, instead of mixing them together.
Our customers run DRCY for design issues and Actions for lifecycle checks as part of the same review workflow.
Is there a rule set for how DRCY finds a datasheet?
Yes. DRCY follows a defined priority order when selecting datasheets for review.
Today, datasheets are prioritized as follows:
Datasheets uploaded directly into the design repository
An internal part library or API, if configured
Datasheet links defined in component attributes
Manufacturer datasheets sourced through DigiKey
DRCY always links the datasheets used in each finding so engineers can see exactly what source informed the review.
You can inspect, verify, and trust every check because the source of truth is visible and traceable.
Does DRCY infer pin functionality from net names?
Net names are one signal, but they are not the only information DRCY has.
DRCY reasons over component configuration and datasheet defined behavior as well as design data such as net names. For example, with regulators or LDOs, it can calculate expected rail voltages based on the circuit configuration, not just what the net is named.
That said, schematic clarity still matters. Clear net naming and correct component configuration improve accuracy, while unconventional patterns can reduce confidence.
DRCY is designed to combine naming, configuration, and datasheet constraints to surface issues early, and this inference continues to improve as coverage expands.
You are not relying on brittle string matching. DRCY uses engineering context to validate behavior, while keeping findings explainable and reviewable.
Can DRCY detect missing ESD protection on headers/buttons?
.png)
In many cases, yes. DRCY looks for patterns within a design rather than relying only on explicit labels. For example, if similar connectors or interfaces in the same design include ESD protection, DRCY can flag comparable interfaces that do not.
This allows DRCY to surface potential gaps where a user touchable interface may be missing protection, even when the external component itself is represented generically.
Clear design patterns and consistency improve accuracy. We are also expanding support for explicit project level guidance so teams can define rules like “all user touchable interfaces require ESD protection.”
DRCY helps catch inconsistencies and missed protections early, before they turn into field failures or rework.
Can we define custom rules or checks for DRCY to run?
Today, DRCY focuses on interpretive design review grounded in schematic context and datasheet constraints, rather than user defined rule authoring.
For custom, deterministic checks, AllSpice Actions are the recommended approach. Actions let teams define explicit rules and validations using structured data, with predictable and repeatable results.
You get higher confidence results by matching the right tool to the right type of check, instead of forcing AI to behave like a brittle rule engine.
How does DRCY handle long, complex datasheets?
DRCY does not try to reason over an entire datasheet blindly.
Instead, it focuses on the portions of the datasheet that are relevant to how the device is actually used in your schematic. It combines schematic context such as pin connections, pin comments, and configuration details with datasheet defined constraints to evaluate expected behavior.
For complex ICs, DRCY prioritizes high impact issues like incorrect power connections, out of range voltages, missing requirements, or configuration mismatches.
You get targeted, explainable findings grounded in real usage, not noise from trying to interpret every possible pin mode or feature.
Can DRCY read schematic tables or notes?
Yes! One of the best ways to increase your review coverage is to add additional context to the schematic.
DRCY will add them to it's context and add checks based on your notes. You can add voltage tables, operation modes, addresses, calculations and DRCY will include them in the evaluations. We're going to be adding more ways to add context in the future.
How long does it take DRCY to analyze a large schematic?
Analysis time varies based on design size, component count, and datasheet complexity.
Currently, for large projects, reviews typically complete in tens of minutes to a couple of hours. DRCY runs asynchronously in the background, so engineers can start a review and return once results are ready.
The goal is to surface meaningful first pass findings without blocking workflow, not to require engineers to wait on analysis.
You get early signal on large designs without slowing down review cadence or tying up engineers.
Can I give DRCY an MCU pin mapping or peripheral config file so it understands how the MCU is used?
Short answer: Not as a standalone config file today, but you can already guide DRCY using schematic context and notes.
How it works today
- DRCY reasons over the actual schematic, net connectivity, component configuration, and datasheets.
- You can use schematic notes, labels, and clear naming to indicate intent like heral usage, alternate functions, or constraints.
- That context is picked up during review and used to evaluate connections, ranges, and common failure modes.
Why this still works well
- The schematic is the source of truth for what is actually built.
- DRCY focuses on catching mismatches between intent, datasheets, and wiring, not just reading config files in isolation.
- This keeps reviews grounded in real design data, not assumptions.
Where this is going
- We are actively working toward more structured ways to provide design intent that generalize across MCUs and projects.
- Customer feedback directly shapes how those inputs evolve, without locking teams into vendor-specific formats.
- The goal is richer context with the same guardrails: inspectable findings and human sign-off.
Bottom line
- You can get value immediately using schematic-driven intent.
- DRCY is designed to grow with your workflows, not force you to change them upfront.
How does DRCY distinguish between common schematic best practice issues and intentional design decisions, especially in areas like power and reset networks where exceptions are often deliberate?
.png)
DRCY looks for patterns, constraints, and datasheet context, not just rule violations. It flags things that commonly indicate risk, especially in power and reset networks, and always shows the evidence it used. Engineers stay in control. DRCY provides early signal, not final judgment.
Can DRCY review PCB layouts?
DRCY can't currently review PCB layouts, however, it is on the roadmap. We do offer many other options for PCB review using AllSpice Actions. Engineers can leverage external DFM tools via API, or add their own checks like courtyard overlap, net classes trace width, trace length, via size/plating, and more.
AllSpice currently offers visual footprint and symbol review, which can help alleviate a lot of PCB issues.
If you'd like to hear more about our roadmap, or what types of PCB checks you can do today, ask us anything!
Can DRCY learn our company specific best practices or be customized in different ways to our unique needs?
You can currently add instructions or best practices as notes in the schematic. DRCY also uses one document per component in addition to the schematic for context.
In the future we will be able to read multiple documents per component, including design and workflow specifications.
Can DRCY recommend components given a spec?
DRCY can't currently recommend components. The problem isn't finding a component that can perform a function, but how to decide among the sometimes thousands of choices. If you'd like to learn more ask us anything!
Can DRCY learn from its mistakes?
You can help the feedback process and improve DRCY's results by reacting to comments. We also meet with your team to hear your feedback.
Can DRCY check multiple boards at once?
DRCY can only currently check one schematic at a time. In the future we will be able to process multiple schematics in a multi-board assembly context.
Still have questions?
Every hardware team works a little differently. Design complexity, compliance requirements, internal tooling, and review culture all shape how DRCY fits into your workflow.
If something is unclear, if you want to validate a specific use case, or if you need deeper technical detail about security, performance, or deployment, we are happy to talk through it.
Ask us anything.
Our team will get you a clear, direct answer.
Whether you are an engineer evaluating first-pass review coverage or a director assessing risk and rollout, we can help you determine if DRCY is the right fit for your team.
Ship with confidence.