Documentation / AI workflows
Give Resin a testable circuit brief, observe its tool work, then verify every generated design fact in the EDA editors.
Outcome
Execution record
| Step | Required role | Starting state | Evidence to retain |
|---|---|---|---|
| 01 / Define a testable brief | Electrical engineer authorized to define the task and approve data use | The disposable-project purpose, data classification, service permission, source documents, and downstream prohibited uses are recorded. | Versioned brief, acceptance table, data-use approval, cited source list, author, date, and task boundary |
| 02 / Record the baseline | Project editor authorized to use Chat in the disposable project | The approved brief is frozen; one disposable project is identified; no AI request for this task is active and no production project is open for accidental edits. | Project identity, file list and counts, saved-state or revision identifier, opening Changes state when available, chat/thread identity, role, and timestamp |
| 03 / Send the complete prompt | Authorized project editor and prompt owner | Step 2 identifies the baseline and empty/task-specific thread; the prompt hash or version and acceptance checks are fixed. | Exact sent user message, thread identity, send timestamp, prompt version, acceptance-check count, and any composer or policy message |
| 04 / Observe tool execution | Prompt owner observing the same task thread | The one approved prompt is visible as the latest user message and the project baseline is retained separately. | Tool-state ledger with labels, order, timestamps when available, completed/failed/unresolved state, final response, and exact error text |
| 05 / Inspect architecture and part choices | Electrical/component engineer authorized to qualify part identity and ratings | Tool execution is complete or explicitly failed; the prompt, part list, source policy, operating conditions, and acceptance table are open together. | Architecture trace, per-part manufacturer/MPN/package/rating/pinout table, source document IDs/revisions, rejected claims, lifecycle assumptions, and owners |
| 06 / Inspect the generated schematic | Electrical engineer independent of the generated response | Mandatory part identities are verified or the affected rows are blocked; the baseline and expected architecture/connectivity table are frozen. | Generated sheet identity, saved state, symbol/net counts, endpoint trace table, pin/electrical-type samples, warning list, baseline delta, and mismatches by requirement |
| 07 / Run deterministic checks | Electrical engineer authorized to edit the disposable project and disposition ERC findings | Step 6 has a complete delta and trace table; ERC rule context and pre-correction project state are recorded; no finding is pre-waived for convenience. | Saved-state identifier, initial/final ERC summaries and exports when available, finding ledger, exact manual or prompt correction, before/after delta, and side-effect review |
| 08 / Close with an engineer decision | Accountable electrical reviewer, not the AI response | Steps 1-7 are complete or explicitly blocked and all retained evidence is linked to one prompt, thread, project state, and rule context. | Signed evaluation record, prompt/thread/project identifiers, requirements trace, source-backed part table, schematic delta, ERC ledger, unresolved owners, and decision |
Procedure
Write the task outside Resin first. Include input and output voltages, interfaces, load limits, environmental or cost constraints, forbidden choices, required deliverables, and at least five acceptance checks. Keep the task small enough to inspect in one session.
Owner-approved AI task record outside Resin / Approved requirements source > bounded prompt and acceptance table: Write one finite task with numeric operating limits, interfaces, forbidden choices, deliverables, source assumptions, and at least five pass/fail checks
The brief contains measurable requirements and no confidential material that is not approved for the service.
Stop ifStop before Chat when requirements are disputed or non-measurable, confidential data lacks approval, authoritative sources are unavailable, or the task cannot be inspected in one bounded session.
Open the disposable project, record its file list and current saved state, then open Chat. Start a New chat when an earlier thread contains unrelated context.
Resin disposable project and Chat / Projects > exact disposable project > project file list and saved state > Chat > New chat: Inventory the project, preserve the saved baseline, open Chat, and start New chat when existing context is unrelated
The project baseline and an empty or task-specific chat thread are identifiable before the prompt is sent.
Stop ifStop before prompting when the project is not disposable, identity or baseline is ambiguous, Chat is unavailable, an unrelated response is active, or the thread contains context that cannot be separated.
Use Describe your circuit design... to provide the brief, source assumptions, and a request to state uncertainties. Send one complete prompt rather than a sequence of unstated corrections.
Resin Chat composer / Disposable project > Chat > task-specific thread > Describe your circuit design...: Enter the approved brief verbatim, request explicit assumptions and uncertainties, compare before send, then send once
The user message in the thread contains the full requirements and acceptance checks verbatim.
Stop ifDo not send when the text differs from the approved brief, data approval changed, the thread identity is uncertain, another response is active, or Send message remains disabled.
While the response runs, watch the named tool states such as Searching parts, Reading datasheet, Selecting component, Setting architecture, Generating schematic, and Updating design notes. Do not treat a done badge as engineering approval.
Resin Chat response and tool-state timeline / Task-specific Chat thread > response execution states: Observe and transcribe each displayed tool label, state, order, failure, and final response status without editing the project during execution
The completed and failed tool states are recorded, and the response finishes without an unresolved working state.
Stop ifStop downstream review when the response remains active, a required tool fails or never completes, project identity changes, or the generated artifact claimed in text is absent from the project.
Compare the response, Architecture, and Bill of Materials with the brief. For every selected part, verify manufacturer identity, exact MPN, ratings, package, lifecycle assumptions, and pinout against the authoritative datasheet.
Resin Chat Architecture and Bill of Materials plus authoritative external sources / Task thread > response > Architecture and Bill of Materials; then approved manufacturer documents for each exact MPN/package: Reconcile every architecture requirement and selected part against the brief and cited authoritative source; assign Verified, Rejected, or Unresolved
Every part is marked verified, rejected, or unresolved with a source; no selection is accepted solely because AI proposed it.
Stop ifStop acceptance when an exact MPN/package is missing, a rating lacks its operating condition, pinout differs, a source is unauthoritative, or any selected part remains unresolved for a mandatory requirement.
Open the generated schematic in Schematics. Count symbols and nets, trace each power and interface path, inspect pin numbers and electrical types, and check visible warnings. A rendered or saved schematic is not proof of electrical correctness.
Resin schematic editor / Task-specific Chat thread > generated artifact in project > Schematics > generated sheet: Open the actual project artifact; inventory symbols/nets and trace each required rail/interface through exact references, pins, labels, junctions, and returns
Every required interface and rail has verified endpoints, and every mismatch is listed against the original acceptance check.
Stop ifStop when no generated sheet exists, sheet identity is ambiguous, a mandatory part is unresolved, an endpoint/return cannot be traced, pin mapping differs, or unrelated baseline objects changed.
Save the generated state, run ERC without changing rules mid-run, and classify every finding. Correct confirmed issues manually or send a follow-up prompt that names the exact object and required change, then inspect the resulting delta again.
Resin schematic saved state, Chat, and ERC / Generated sheet > Save; schematic empty-area context menu > Run ERC > ERC dock; optional task thread follow-up: Save, run ERC to completion, classify every row, apply at most one bounded correction per failed criterion, then Re-run with the same rule context
The final ERC count and all remaining findings are recorded; follow-up changes are linked to specific failed checks.
Stop ifStop when ERC fails or is incomplete, rule context changes, the target object is not unique, a correction changes unrelated objects, or a requirement remains failed despite a clean configured ERC result.
Record the prompt, project revision or saved state, parts reviewed, checks run, unresolved assumptions, and the decision to accept for further engineering, revise, or discard. Do not release manufacturing data from this AI task alone.
AI task evaluation record / Outside Resin > named AI task record linked to the project state and Chat thread: Disposition every requirement, part, tool state, schematic trace, ERC finding, change, exception, and prohibited downstream claim
Another engineer can reproduce the task and understand exactly which output was verified and which claims remain unproven.
Stop ifDo not publish Accept for further engineering when a mandatory row is failed/unreviewed, evidence is detached from the project state, an AI claim substitutes for a source, or the record implies release approval.
Verification
Evidence and exercise files
CSV / Resin evaluation record
Provenance: Repository-tracked worksheet for prompt scope, sources, proposed changes, independent checks, rejected claims, and final disposition.
Current limit: This is an evaluation schema, not a completed AI task or evidence that a generated answer is electrically correct.
Download fileEvidence boundary
Failure recovery
Chat, Send message, or a required tool step is unavailable, disabled, failed, or left in a working state.
Diagnosis: Record project and thread identity, role, prompt presence, active-response state, exact control/tool label, displayed status, error text, timestamps, and whether any artifact appeared.
Recovery: Preserve the prompt and thread, wait only for an active request to settle, then make one retry in a new task-specific thread from the unchanged baseline when the failure state is complete and retry is authorized.
Stop or escalate: Escalate when availability differs for an authorized editor, the same tool state fails twice, completion remains ambiguous, or retry could duplicate or overwrite project changes.
Evidence: Baseline, prompt version, thread IDs, tool-state ledger, exact errors, retry decision/result, product context, role, and issue owner
Recheck: The retry reaches a terminal state and every claimed artifact exists in the named project; otherwise the task remains Blocked and no generation claim is retained.
The response invents or conflicts on a part, rating, pin, architecture statement, or generated-schematic connection.
Diagnosis: Identify the exact claim, MPN/package/reference/pin/net, governing requirement, authoritative source and revision, observed project object, and resulting acceptance-row impact.
Recovery: Reject the claim, keep the affected requirement blocked, and correct only through an engineer-approved source-backed edit or one follow-up naming the exact object and required bounded change.
Stop or escalate: Escalate when sources conflict, the exact part/package cannot be established, the follow-up changes more than the named object, or the correction requires redesign beyond the frozen brief.
Evidence: Response excerpt, source citation, project-object capture, rejected-claim row, correction request or edit, exact delta, and engineering owner
Recheck: The corrected project value equals the cited source and requirement, the complete affected path is retraced, and no unrelated object or acceptance row changed.
ERC is clean or improved while a written requirement remains unmet, or a follow-up changes unrelated project objects.
Diagnosis: Compare the frozen requirement table, baseline delta, first/final ERC rows and rule context, follow-up message, and every unrelated added, removed, or modified object.
Recovery: Keep the requirement failed, discard or revert the disposable state to the retained baseline when authorized, and issue no broader follow-up until one exact correction and its verification are defined.
Stop or escalate: Stop when baseline restoration is uncertain, unrelated changes cannot be enumerated, rule context differs, or deterministic checks cannot evaluate the requirement being claimed.
Evidence: Requirement disposition, baseline and changed-state inventories, ERC records, follow-up text, object delta, restore/discard decision, and unresolved owner
Recheck: The project returns to the known baseline or contains only the approved bounded delta; the requirement is independently Met or remains explicitly Failed/Unresolved regardless of ERC count.
Task-specific troubleshooting
Confirm an editable project is selected, the prompt is non-empty, and no response is still streaming. Do not move the task to a production project as a workaround.
Preserve the prompt and thread, wait for the active request to finish, and record the failure state before retrying in a new thread.
Treat the associated output as incomplete. Record the exact tool label and do not infer that later text repaired the missing operation.
Reject the claim, cite the authoritative source, and correct the design only after the exact MPN and package are established.
Check the project file list and task thread, then preserve the tool states. Do not claim generation from a text response alone.
Record the exact reference, net, and requirement mismatch. Prefer a small explicit correction over asking the AI to redesign everything.
Stop, compare against the recorded baseline, and revert or discard the disposable project state before issuing a narrower request.
Keep the requirement failed. ERC checks configured electrical rules; it does not prove ratings, performance, sourcing, or regulatory compliance.
Decision gate
Approved brief and data-use record, baseline, exact prompt/thread, tool-state ledger, source-backed part table, generated-artifact identity, connectivity trace, initial/final ERC records, correction deltas, unresolved owners, and signed decision
A tool state is unresolved, a mandatory claim lacks a source, a part or pin conflicts, the generated artifact is absent, unrelated objects changed, a requirement remains failed, or AI/ERC output is being used as release proof.
Next decision
Use the evaluation kit to choose a representative input and define the result your team needs.
ExecuteRun the task in ResinUse an approved project or disposable copy and preserve the actual result separately from this guide.
ContinueRun and triage ERCAdvance only within the scope permitted by the completed decision gate.