Plan FDX1-FDX6 IR-native datasheet extraction

[akiselev]

Summary

Defines the Datasheet-cli side of the FDX program: replace the current remote-PDF-LLM-centered architecture with a reusable electronics compiler, weak-supervision data engine, compact local model, and progressive production cascade.

The plan is split one implementation PR per phase:

• FDX1 — workspace split and durable DatasheetSketch, EvidenceAnchor, predicate-vocabulary and ClaimBundle contracts;
• FDX2 — deterministic characteristics-table compiler and protected baseline;
• FDX3 — full weak-supervision compiler, including TI/DigiKey/Mouser/manufacturer/EDA/CMSIS/SVD labeling functions, source vocabulary maps, LabelVote, lineage-aware agreement, probabilistic labels and rights gates;
• FDX4 — table-template propagation, synthetic IR/rendered degradations, family/template/manufacturer split discipline and trusted evaluation corpus;
• FDX5 — ELECTRA-Small-class IR-native model, structural embeddings, predicate retrieval/reranking, multi-task losses, ONNX/RTen model bundle, quantization/compute gates and active remote teacher;
• FDX6 — P0-P5 production cascade, targeted Ferrodoc refinement, explicit whole-PDF remote last resort, cache/derivation boundaries, feedback and drift/retraining loop.

Central safety property

The learned model chooses existing predicate/value/regime/condition/subject candidate IDs. It has no free-form engineering-value output. Deterministic code validates those IDs against the pinned DatasheetSketch/DocumentIR and constructs the ClaimBundle.

Initial scope

Qualify the system first on analog/power datasheet sections:

• Absolute Maximum Ratings
• Recommended Operating Conditions
• Electrical Characteristics
• Thermal Information

Existing Gemini extraction remains an explicit fallback/teacher and compatibility path while the local path is developed and qualified.

Companion PRs

Foundry integration: https://github.com/akiselev/foundry/pull/5

Ferrodoc FDX0: akiselev/ferrodoc#4

Validation

Planning/docs-only PR. Branch comparison against master is clean and adds seven files under docs/fdx/, covering the full FDX1-FDX6 implementation sequence.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7f3278db28

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Serialize condition candidates before referencing them

When a row has test conditions or linked footnotes, this ID cannot be resolved: DatasheetSketch/v1 has no conditions[] collection, and no ConditionCandidate record is defined anywhere in the added FDX documents, even though FDX2 explicitly emits these candidates. Since the contract requires unresolved IDs to fail closed, conditioned claims will either become invalid or lose their applicability semantics; add an anchored condition-candidate type and owning serialized collection.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Keep every held-out group disjoint from training

Allowing the first four slices to overlap permits a training example to also appear in development or template-held-out; moreover, the later exclusion only protects document-family and final partitions, leaving template- and manufacturer-held-out groups able to occur in training under distinct document-family IDs. In those cases model selection and reported held-out metrics are contaminated by the exact examples or grouping factor they are intended to test, so only evaluation tags should overlap one another and every evaluation partition must remain disjoint from training at its declared grouping level.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Decouple corpus family assignment from the sketch

A standalone FDX1/FDX2 compilation from pinned DocumentIR cannot populate this mandatory field reliably because document families are not defined until FDX4, where they depend on corpus-wide revision, near-duplicate, and source-relation signals. Assigning or correcting the family later would mutate the serialized sketch and its digest, invalidating downstream candidate identities and caches; keep family assignment in training/dataset metadata, where it is already represented, or define an optional externally supplied value whose updates do not alter the deterministic sketch.

Useful? React with 👍 / 👎.