AI-Assisted Schematic Ingestion and Human Review

How an AI turns a schematic into reviewed circuit data through a web application

Executive summary

The new schematic-ingestion tool is a human-in-the-loop pipeline: an AI worker receives a schematic, optionally receives a predefined amplifier-family profile, extracts components and connections, and submits its work to a browser-based review manager. The worker might be Claude, GPT, or another capable vision-and-reasoning model; the durable interface is the structured extraction package and review protocol, not a model-specific prompt.

The schematic collection can thereby become a much more accurate, searchable, and AI-friendly research resource by adding a component-and-connectivity netlist layer beneath the existing amplifier database. An AI can perform most of the transcription, but it can also be confidently wrong, so it cannot be relied upon to identify every ambiguity in its own work.

The controlling rule is consequently broader than “flag unreadable material”:

Never guess; preserve the source; attach evidence to extracted facts; detect disagreements independently; route every uncertainty or validation failure to review; and publish only after a human-verifiable acceptance gate.

Manual review is the essential safety valve, but flags alone are insufficient. Accuracy also requires immutable source provenance, fact-level evidence, separate extraction and interpretation passes, independent comparison, deterministic electrical checks, completeness accounting, a rendered source-to-netlist comparison, revision control, and explicit publication states. These features make silent error harder and make correction inexpensive when an error is eventually found.

A local manager web application should therefore be a core part of ingestion rather than a report viewer added afterward. It presents the source and reconstructed circuit side by side, focuses the reviewer on small flagged regions, records standardized resolutions, shows validation failures, tracks complete visual-review coverage, and publishes only validated artifacts. The manager turns the existing 5E3 crop-and-flag method into a repeatable production system and gives the AI a feedback channel for improving later scans and classifications.

The authoritative product should not be a raw SPICE file or a drawing. It should be a strict, versioned circuit-data package describing components, pins, nets, controls, source evidence, review issues, and publication history. KiCad schematics, SPICE variants, readable reports, database rows, graph indexes, and AI context should all be generated from that package. The existing amp, preamp, preamp_stage, poweramp, and supply tables then remain the semantic summary layer rather than being forced to carry every wire and component.

1. Objective and accuracy standard

The objective is to preserve each distinct schematic as a traceable electrical graph that can answer detailed questions without requiring the original image to be reinterpreted each time. Examples include finding every amplifier with a particular tone network, comparing exact coupling values, tracing all switch-dependent paths, identifying structurally shared circuits, generating research datasets, and giving future AI systems unambiguous circuit context.

“Foolproof” should not mean that the extractor can never make a mistake. No AI or human transcription process can guarantee that. It should mean that the system is fail-closed, auditable, and cheap to correct:

• Unknown information remains unknown rather than becoming a plausible value.
• Unresolved blocking issues prevent verified publication.
• Every material fact can be traced back to a source region or documented derivation.
• Independent checks can expose mistakes the original extractor did not notice.
• Verified and unverified facts cannot be confused in ordinary search results.
• A correction creates a new revision and preserves the earlier decision history.

This is a stronger and more operational standard than attaching a single confidence label to an entire amplifier row.

2. Relationship to the existing project

The repository already contains several pieces of the intended system:

• sources/ preserves factory drawings, redraws, layouts, and other source material.
• kicad/5f1/ and kicad/5e3/ contain generated schematics, netlists, ERC results, and written interpretation notes.
• The 5E3 work includes cropped problem regions and recorded human resolutions.
• The database uses verified, inferred, coarse, and unknown confidence values.
• Unknown database fields are left NULL rather than guessed.
• Build-time checks reconcile preamp-stage detail with gain-stage rollups and reject broken row references.
• Append-only write logs record authorship, vetting, correction, and deletion.

These are valuable foundations, but they are currently distributed among Python netlist generators, KiCad output, Markdown notes, PNG crops, SQL seeds, and database logs. The proposed system makes those practices uniform and connects them through one controlled lifecycle.

The current contest webapp is the first operational version of this idea. It accepts a schematic PDF, assigns it to an AI worker, watches the result arrive, displays the source beside the extracted component list, and lets a human save a grade and critique. The production ingestion tool should retain that simple loop while adding profiles, field-level evidence, issue resolution, coverage tracking, graph comparison, and a publish gate.

The component netlist should sit below the current relational model:

immutable source drawing
          |
          v
canonical circuit-data package  <---- evidence, issues, reviews, revisions
          |
          +----> human-readable schematic and report
          +----> KiCad schematic and electrical netlist
          +----> SPICE-oriented exports
          +----> graph and full-text search indexes
          +----> amp/preamp/poweramp/supply summaries

The existing summary database remains useful for quick topology comparisons. It should increasingly be populated or checked from verified circuit packages rather than serving as an unquestioned source for them.

3. Canonical circuit-data package

3.1 Why raw SPICE or KiCad should not be authoritative

SPICE is designed for simulation, not archival transcription. It often requires modeling choices that are absent from a factory schematic, and it handles jacks, rotary controls, switching logic, transformer construction, and alternate operating states awkwardly. A simulation-ready netlist can therefore contain more assumptions than the source supports.

KiCad is excellent as a view and interchange target, but a generated .kicad_sch file contains presentation detail and tool-specific structure that make fact-level provenance, uncertainty, and review history difficult to express. The current Python netlist generators are readable to a programmer, but they mix component placement, symbol selection, and electrical assertions in executable code.

The authoritative layer should instead be tool-neutral circuit data. Visual drawings and simulation formats should be reproducible outputs.

3.2 Recommended package layout

Each source drawing or genuine drawing revision should have its own package directory:

circuits/<maker>/<model>/<source-revision>/
    manifest.json
    components.jsonl
    nets.jsonl
    controls.jsonl
    evidence.jsonl
    issues.jsonl
    reviews.jsonl
    generated/
        circuit.kicad_sch
        circuit.net
        circuit.spice
        circuit_readable.yaml
        validation.json
        review_render.svg

Strict JSON and JSON Lines are preferable for the authoritative records because parsing, schema validation, duplicate-key rejection, and deterministic generation are more reliable than unrestricted YAML. A sorted YAML export can still provide the compact human- and AI-readable view originally contemplated. The manager application removes the need for people to hand-edit the strict representation.

The exact file split may change during the pilot. The important architectural rule is that source facts, evidence, review decisions, and generated artifacts are distinct and machine-validated.

3.3 Required fact structure

Every extracted fact should distinguish the source inscription from its normalized meaning. A component record would contain fields such as:

{
  "component_id": "R17",
  "kind": "resistor",
  "value_raw": "56K",
  "value_normalized": "56k",
  "pins": ["1", "2"],
  "source_evidence": ["ev-page1-r17"],
  "basis": "source-visible",
  "confidence": "verified",
  "review_status": "accepted"
}

At minimum, the model needs to represent:

• Components, reference designators, raw markings, normalized values, tolerances, ratings, and annotations.
• Device units and physical packages, including tube sections, heaters, shared cathodes, and unused sections.
• Nets as endpoint sets rather than only visually named wires.
• Page connectors, buses, rail aliases, shields, chassis ground, earth, signal ground, and supply returns without collapsing distinct symbols prematurely.
• Transformer windings, center taps, polarity marks, tap labels, and uncertain internal construction.
• Potentiometer terminals and wipers without assuming a clockwise orientation not stated by the drawing.
• Jack normal contacts and their inserted/uninserted states.
• Switch poles, throws, gangs, mechanical linkage, default position, and complete state tables.
• Relays, optocouplers, FET switching, logic control, and state-dependent audio paths.
• Optional components, production alternatives, field modifications, and explicitly crossed-out or “not fitted” parts.
• Off-page references and multi-sheet hierarchy.
• Test points, voltages, waveforms, layout-only information, and textual notes.
• Explicit unknowns when a value, symbol, pin, junction, or state cannot be determined.

3.4 Separate observation from interpretation

The package should preserve three different kinds of knowledge:

This distinction prevents a familiar circuit pattern from contaminating the transcription. Existing database facts and family resemblance may be used to raise a contradiction, but they must not silently replace what is drawn.

3.5 Predefined profiles as controlled prior knowledge

A profile is optional guidance supplied before extraction. It can describe the expected drawing conventions, likely tube families, common component notation, known stage-count rules, and recurring traps for a circuit family. A 5F2-A profile, for example, can remind the worker to look for the two 12AX7 triode sections, single-ended 6V6 output stage, 5Y3 supply, unusual tone-control wiring, and the global negative-feedback path.

The profile is a checklist and a source of hypotheses, not permission to fill in missing facts. The worker must still cite each value and connection to the current scan, explicitly record absences, and flag contradictions between the profile and the drawing. This makes profiles useful for scan optimization and classification accuracy without turning family resemblance into fabricated evidence.

4. End-to-end workflow

4.1 Source intake and preservation

The system first registers the exact source before attempting interpretation:

1. Store the original file without destructive preprocessing.
2. Calculate a cryptographic hash and stable source identifier.
3. Record filename, provenance, page count, drawing title, printed revision, and known acquisition source.
4. Detect byte-identical and visually near-duplicate files.
5. Render pages using a pinned tool version and resolution.
6. Preserve alternate contrast, threshold, deskew, and enlargement renders as derived views, never replacements for the original.
7. Associate layouts, service notes, and alternate scans without merging their claims.

OCR is useful for locating reference designators and candidate values, but it is an extraction aid rather than evidence. Evidence remains the drawing region itself.

4.2 Page and object inventory

Before tracing connectivity, Sol should inventory everything visible:

• Drawing title blocks and revision notes.
• Page-to-page connectors.
• Component symbols and reference designators.
• Unlabeled symbols and notes.
• Junction dots, crossings, buses, shields, and ground symbols.
• Control linkages and switch-state tables.
• Regions that appear unreadable, clipped, or missing.

Completeness accounting begins here. Every visible electrical object must eventually be classified as extracted, intentionally excluded, duplicated elsewhere, or covered by an issue. This catches omissions that ordinary ERC cannot detect because a completely omitted branch produces no malformed net.

4.3 Multiple focused extraction passes

One broad “read the schematic” prompt encourages premature pattern completion. The work should be divided into passes with constrained outputs:

1. Identity pass: drawing title, model, revision, pages, and source relationships.
2. Symbol pass: devices and reference designators without connectivity guesses.
3. Value pass: raw inscriptions and normalized values.
4. Connectivity pass: endpoint-to-endpoint nets, including crossings and junctions.
5. Control-state pass: switches, jacks, relays, and every supported state.
6. Power pass: mains, heaters, grounds, rectification, bias, and supply rails.
7. Functional pass: stage roles, channel paths, feedback loops, and derived database summaries.
8. Completeness pass: compare the extracted object map with every source region.

A later pass may raise an issue against an earlier result, but it should not rewrite it invisibly.

4.4 Independent comparison

At least one verification pass must be independent of the original extraction context. It should reconstruct component and connectivity facts from the source, then compare graphs rather than merely proofreading Sol’s prose.

Differences become explicit issues:

• Missing or extra component.
• Value disagreement.
• Pin or tube-section disagreement.
• Net membership disagreement.
• Junction-versus-crossing disagreement.
• Switch-state disagreement.
• Page-connector mismatch.
• Source revision mismatch.

Independence matters because asking the same system to “check its work” while showing it the original answer encourages confirmation rather than detection.

4.5 Deterministic validation

Validation should combine format, electrical, completeness, and project-specific checks.

Structural checks:

• JSON Schema conformance and canonical ordering.
• Unique identifiers and reference designators within their intended scope.
• Valid device types and valid pin names.
• Every net endpoint references an existing component pin.
• Every evidence reference and review reference resolves.
• No generated file is newer than or inconsistent with its canonical input.

Electrical checks:

• Unexpected isolated nets and dangling pins.
• Shorted supply rails or collapsed ground domains.
• Impossible connections between units of the same tube.
• Heater continuity and rectifier winding plausibility.
• Output-transformer primary, center-tap, secondary, and feedback connectivity.
• Potentiometer wiper and jack-normal completeness.
• Switch poles with missing throws or impossible simultaneous states.
• Off-page labels that appear on only one page or map inconsistently.

Project-specific checks:

• Tube complement reconciles with all used and unused device sections.
• Counted preamp stages reconcile with the explicit signal path and the repository’s counting rule.
• Phase inverter and output topology agree with the graph.
• Supply summaries agree with rectifier devices and rail topology.
• Existing database claims that conflict with the extracted graph are reported, not automatically preferred.
• Deduplicated circuit-body claims are re-evaluated when the component graph differs.

Rules must distinguish an error from a warning. A deliberately unused tube section or floating shield can be legitimate, but it needs an explicit disposition rather than being silently ignored.

4.6 Visual round-trip review

The canonical graph should generate a clean review schematic. The reviewer then compares the source and generated view side by side or as an overlay.

Bidirectional highlighting is important:

• Selecting R17 highlights its source region and both connected nets.
• Selecting a source wire highlights the reconstructed net and all endpoints.
• Selecting a net reveals every source segment that supports it.
• Selecting a switch state redraws or highlights the active signal path.

This is the principal defense against a confident but structurally valid mistake. ERC can confirm that a wrong circuit is internally consistent; only source comparison can show that it is not the circuit on the page.

4.7 Human acceptance

Human review should have two scopes:

1. Issue review: resolve every flagged ambiguity, disagreement, and failed check.
2. Coverage review: perform a complete visual sweep of the source-to-render correspondence, not merely the locations Sol chose to flag.

The manager should track coverage by page regions, components, and nets. A reviewer can approve a page only after all visible electrical content has been inspected or dispositioned. This limits the risk that an unflagged AI mistake bypasses the human entirely.

5. Review issues and fail-closed publication

5.1 Standard issue record

Each issue should contain:

• Stable issue identifier.
• Source page and image coordinates.
• One or more automatically generated crops.
• Category and severity.
• The exact fact or graph element affected.
• Candidate readings or interpretations, when useful.
• Dependencies and downstream impact.
• Blocking or nonblocking status.
• Extractor explanation and independent-check result.
• Human resolution, reviewer, timestamp, and rationale.
• Any replacement source or corroborating evidence used.

Useful issue categories include illegible value, ambiguous junction, ambiguous reference designator, unknown device, uncertain pin mapping, page-connector mismatch, missing page, clipped source, switch-state ambiguity, source conflict, likely drawing error, model/revision conflict, validator failure, and database contradiction.

5.2 Allowed resolutions

The application should provide standardized resolutions rather than an unstructured comment box alone:

• Confirm a specific reading or connection.
• Confirm that the item is absent or not connected.
• Mark the source as genuinely indeterminate.
• Defer pending a better source while keeping publication blocked.
• Accept a documented source error without “repairing” the archival transcription.
• Link a corroborating source and record which source controls.
• Split a mixed or revision-conflicted package into separate circuits.
• Mark the object as non-electrical or outside the package scope.

Free-form notes remain available for reasoning, but the structured disposition makes later searching and auditing possible.

5.3 Publication states

Confidence and workflow state must remain separate. A fact may be source-stated but coarse, or human-resolved and verified. Recommended package states are:

No package may become human_verified while it has unresolved blocking issues, incomplete source coverage, stale generated artifacts, or failed required validators.

6. Accuracy features beyond manual flags

Manual flags address recognized uncertainty. The following features address uncertainty the extractor fails to recognize.

Additional operational safeguards are also required:

• Pinned toolchain: record renderer, OCR, schema, symbol-library, and generator versions.
• Reproducible generation: identical canonical input must produce semantically identical outputs.
• Structural hashing: compare graphs independent of reference-designator renumbering where useful, but never deduplicate solely on a hash collision or superficial similarity.
• Controlled vocabularies: device types, confidence, basis, issue categories, and resolutions must be schema-defined.
• No hidden repair: validators may propose a correction but cannot apply it without creating a visible revision or review action.
• Negative knowledge: “verified absent,” “not legible,” and “not examined” must remain distinguishable.
• Source hierarchy: a factory drawing, service-manual reprint, trusted redraw, layout, and secondary description can corroborate each other but are not interchangeable.
• Concurrency control: a package should use review leases or optimistic locking so two agents or reviewers cannot silently overwrite each other.
• Backup and migration tests: schema upgrades must preserve packages and reproduce prior exports before becoming active.
• Sampling and metrics: monitor issue rates, post-publication correction rates, extractor disagreement, review time, and common failure categories by source quality.

7. Manager web application

7.1 Why the manager should be a core component

At collection scale, Markdown notes and loose crop folders will produce inconsistent issue descriptions, incomplete resolutions, and forgotten review work. A manager application is not merely a convenience. It is the practical enforcement point for the accuracy contract.

The application should be local-first and run against repository-controlled files. Network deployment and multi-user authentication can be added later if needed. The first priority is making one reviewer fast, consistent, and unable to publish incomplete work accidentally.

7.2 Primary workspaces

Intake dashboard

• Lists unregistered sources, duplicates, revisions, page counts, and render status.
• Displays title-block candidates and known database matches.
• Requires an explicit source identity before extraction begins.

Extraction workspace

• Shows a zoomable high-resolution source page.
• Overlays detected symbols, text, wires, junctions, and page connectors.
• Displays the structured component/net editor beside the page.
• Allows the assigned AI worker to submit facts and issues through a validated API rather than editing files freely.
• Keeps source observations, normalized values, and interpretations in separate fields.

Review queue

• Sorts by blocking status, issue type, source quality, and downstream impact.
• Presents a tight crop, surrounding context, candidate readings, and affected graph.
• Supports keyboard-driven accept, correct, unknown, defer, split, and source-error actions.
• Prevents bulk acceptance of high-risk categories such as junctions, switch states, and transformer pin mappings without an explicit policy.

Graph and schematic comparison

• Presents source, generated schematic, and graph views with synchronized selection.
• Supports overlay opacity, difference emphasis, and a trace-the-net mode.
• Displays alternate switch or jack states and the resulting signal paths.
• Marks reviewed components, nets, and source regions so coverage gaps are visible.

Validation and publication

• Runs all required checks and explains failures in plain language.
• Shows extraction-pass disagreements and database contradictions.
• Displays stale outputs or tool-version changes requiring regeneration.
• Requires named human signoff for human_verified publication.
• Produces the canonical package, generated artifacts, summary database proposal, and append-only review event together.

Search and research explorer

• Searches components, normalized values, raw markings, nets, stages, controls, and source notes.
• Defaults to human-verified data with an obvious option to include drafts or unknowns.
• Shows provenance and uncertainty beside every result.
• Supports graph queries such as “find circuits with this local topology” without collapsing distinct source revisions.

7.3 Review experience details

The manager should minimize the cost of careful review:

• Precompute multiple image renderings and let the reviewer toggle them instantly.
• Keep zoom and location synchronized across original, enhanced, and alternate-source scans.
• Generate crops automatically but allow the reviewer to expand context.
• Offer candidate values only as choices, never as a default silently selected.
• Highlight every downstream fact that will change with a resolution.
• Require a reason when overriding a higher-quality source or accepting a validator exception.
• Support “cannot determine” as a successful review outcome.
• Save continuously while preserving immutable event history.
• Permit comments and later reopening without changing previously published revisions in place.

7.4 Suggested architecture

A practical initial stack is a local Python service, SQLite working database, repository-backed canonical packages, and a browser interface. This aligns with the repository’s existing Python build tooling and SQLite database while keeping the canonical artifacts reviewable in Git.

The working database should manage queues, locks, indexes, and UI state. It should not become the only copy of the circuit facts. Publication writes a deterministic package to the repository, regenerates outputs, records hashes, and creates an append-only event. A fresh manager database should be rebuildable from those packages.

The web API should expose domain operations such as resolve_issue, connect_endpoint, split_net, approve_page, and publish_revision, not unrestricted row updates. Domain operations can enforce invariants and make every meaningful change auditable.

The manager should treat the AI worker as an authenticated workflow actor with limited operations. Claude, GPT, or another model may propose extraction records, crops, candidates, and corrections; only validation and publication services may advance package state.

8. Search, AI use, and database integration

The verified circuit packages should feed three complementary query layers:

1. Literal graph layer: components, values, pins, nets, and state-dependent connectivity.
2. Derived circuit layer: gain stages, tone networks, phase inverters, feedback, supply topology, and reusable structural fingerprints.
3. Research assertion layer: cited technical claims, measurements, explanations, and comparisons.

Future AI queries should receive the smallest relevant verified subgraph plus provenance, not an entire PDF or a context-heavy raw netlist. For example, a query about a cathodyne could retrieve the phase-inverter device, its connected resistors and capacitors, the feeding stage, the output grids, relevant source crops, and any unresolved issues.

The current amplifier database should be integrated conservatively:

• Package-to-database derivation proposes amp, preamp, preamp_stage, poweramp, and supply values.
• Existing values are compared and discrepancies become reviewable changes.
• Summary rows never overwrite literal source facts.
• Current write-log concepts extend to package revision, review, and generated database writes.
• The existing confidence vocabulary is retained, while basis and workflow state are stored separately.
• Deduplication occurs after verified structural comparison; distinct drawings remain separately traceable even when they share a deduplicated circuit body.

9. Pilot and implementation sequence

Phase 0: Define invariants and golden sources

• Finalize the minimum circuit schema, evidence record, issue model, and state machine.
• Record the no-guess, no-hidden-repair, evidence-required, and verified-only-search invariants as executable tests.
• Finish the 5F2-A characterization, including a reviewed account of its tone-pot wiring, unbypassed feedback-injection cathode, B+ reservoir, tube classifications, and all source ambiguities.
• Establish a golden set containing 5F2-A, the already available 5E3 and 5F1 results, a complex switched amplifier, a multi-page modern design, and a poor scan.

Phase 1: Canonical format and command-line validator

• Convert the characterized 5F2-A into the first canonical package and preserve its profile separately from its observed facts.
• Generate its readable export and KiCad representation.
• Implement schema, identifier, pin, evidence, completeness, and core electrical validators.
• Compare the result component-by-component against the existing 5F2-A artifacts and factory source.

Phase 2: Review manager minimum viable product

• Implement source registration, tiled image viewing, overlays, issue records, review actions, coverage tracking, validation, and publication.
• Apply the 5F2-A profile to another simple 1950s Fender schematic. 5E1 is the best next test because it is related but not identical; 5E3 is also useful as a manager-import case because its existing extraction, flag crops, and human resolutions already expose difficult control and phase-inverter details.
• Import existing 5E3 flag crops and human resolutions as historical review events.
• Confirm that the system can express shared cathodes, unusual control wiring, cathodyne details, and resolved uncertainties without prose-only exceptions.

Phase 3: Independent extraction and difficult cases

• Add independent graph comparison and disagreement generation.
• Add multi-page connectors, switch and jack state models, transformers, and alternate-source alignment.
• Process one complex switching amplifier, one poor scan, and deliberately adversarial edge cases such as missing pages, clipped values, ambiguous junction dots, duplicate references, and contradictory profile hints.
• Refine issue categories and reviewer ergonomics using measured review time and error discovery.

Phase 4: Search and current-database integration

• Build verified graph indexes and component/value search.
• Generate proposed summary rows and compare them with amps.db.
• Add structural fingerprints and source-revision comparison.
• Make provenance and unresolved facts visible in all result presentations.

Phase 5: Controlled scale-up

• Process a representative batch across makers and source qualities.
• Measure extraction agreement, issues per page, human review time, correction rate, and validator yield.
• Freeze a versioned production schema only after the pilot covers the difficult cases.
• Increase throughput gradually while continuing full visual signoff for human_verified status.

Immediate engineering backlog

The work should proceed as a short, measurable loop rather than as a large speculative build:

1. Finish and sign off the 5F2-A characterization and profile.
2. Run the profile against 5E1, recording which expectations transfer and which create false confidence.
3. Improve the UI for issue queues, source-to-net highlighting, coverage maps, and explicit unknown/resolve actions.
4. Improve schematic and overlay viewers: higher-resolution crops, synchronized zoom, opacity controls, difference highlighting, and net tracing in both directions.
5. Test edge cases and chase bugs in upload, assignment, result parsing, review persistence, and stale-artifact detection.
6. Add independent comparisons and validator checks before widening the model or amplifier set.

10. Acceptance criteria

A package should qualify as human_verified only when all of the following are true:

• The source file, pages, rendering process, and hashes are registered.
• Every visible electrical object and source region is extracted or explicitly dispositioned.
• Every asserted component value and connection has source evidence or a documented derivation.
• Raw inscriptions and normalized values are both preserved where normalization occurs.
• Independent extraction differences are resolved.
• Required structural, electrical, completeness, and project-specific checks pass.
• All switch, jack, relay, and alternate states in scope are represented or explicitly excluded.
• The generated review schematic is current with the canonical package.
• A human completes source-to-render coverage review, not only issue review.
• All blocking issues are resolved; genuine source uncertainty remains represented as unknown.
• Database-derived summaries reconcile or create explicit correction proposals.
• The review, publication event, tool versions, and artifact hashes are recorded.

These criteria deliberately allow a verified package to contain unknown values. Verification means the package faithfully represents what can and cannot be established from its sources; it does not mean every printed fact was legible.

11. Principal risks and boundaries

The hardest remaining constraint is human attention. A manager can make review much faster, but it cannot eliminate the need to inspect the complete reconstructed circuit if the desired status is genuinely verified. The workflow should optimize that attention rather than pretend it is unnecessary.

Conclusion

AI-generated netlists can transform the schematic archive from a collection of images into a durable circuit research system. The safe architecture is not “AI transcription plus a confidence score.” It is a layered evidence and review process in which strict circuit data is authoritative, uncertainty is first-class, independent checks expose unrecognized mistakes, and human signoff is tied to complete source coverage.

The existing 5F1 and 5E3 work proves that the repository already has useful ingredients: generated KiCad artifacts, ERC, targeted connectivity validation, source crops, explicit flags, human resolutions, confidence values, and append-only provenance. The next step is to formalize those ingredients in a canonical package and a local manager web application.

The manager should be developed during the pilot, beginning with 5F2-A and then 5E1, while importing the existing 5E3 work. It will standardize how any chosen AI submits facts, how ambiguities are resolved, how complete review is demonstrated, and how verified packages feed search and the existing database. This makes “foolproof” a practical systems property: mistakes may still be attempted, but they become difficult to publish silently, straightforward to locate, and safe to correct.