AI-Native Powerby Rafael Collado

START HERE / RUNNABLE PREVIEW

Check when a rule is enough, then try a grouped model.

Start with the simplest engineering rule. Expose a direct-label shortcut, hold out complete converter designs, compare the same errors, and state exactly what the second result cannot prove.

Synthetic teaching data only. Not target-user tested. Not hardware validation, design approval, or evidence of transfer to your converter.

EVIDENCE CONTRACT

Four labels keep a tutorial from becoming an unsupported claim.

They are used as evidence states, not decorative emphasis.

BEFORE YOU START

Know the input, environment, output, and boundary.

The route supports a programming novice without simplifying the power-electronics context.

Starting knowledge
Comfort reading converter operating points and tabular results.
ML level
No prior machine-learning project is assumed by the Guided path.
Input
Two included synthetic teaching tables; do not substitute confidential data.
Execution
A pinned local Python runner; notebooks are included but no cloud service is required.
Output
A rule-versus-model decision, a grouped proxy comparison, frozen predictions, and written limits.
Time
UNKNOWN, completion time has not been measured with target users.
DATA HANDLING

Do not upload confidential designs, proprietary simulator models, credentials, export-controlled material, customer data, or personal information to a public notebook or AI service. Use an approved local environment when the data requires it.

CHOOSE YOUR SUPPORT LEVEL

The engineering method stays fixed. Only the programming help changes.

Both routes use the same files, grouped split, metrics, and evidence boundary.

GUIDED

Python or notebooks are new to me.

Follow what to install, what to run, what output to expect, and why each check exists.

  1. Read README.md and NOTICE.md before opening any file.
  2. Run run_starter.bat from the extracted directory.
  3. Compare current outputs with results/expected.
  4. Use checklist.md before considering another authorised dataset.
Use the Guided path ↗

COMPACT

I already work with Python.

Inspect the manifest and notebook contract, reproduce the run, then move directly to the held-out result and limits.

  1. Verify the ZIP and internal manifest hashes.
  2. Run VERIFY_PACKAGE.py and run_starter.py.
  3. Inspect both notebooks and frozen predictions.
  4. Review shortcuts, group overlap, confusion matrices, and authority limits.
Use the Compact path ↗

PUBLIC STARTER KIT / V0.2.1-PREVIEW

Make the rule-versus-model decision before choosing complexity.

The package is public and requires no email. It contains the exact two datasets, executed notebooks, runner, checklist, manifest, seeds, predictions, expected outputs, provenance, and licence.

ZIP SHA-2563ec6b01c72118bdbec60cf5516dda55ceb5d66ecfa7f384deb8638211d4df21a

EXERCISE 1USE RULE, NOT ML
WHYExact rule F1 1.000 / logistic_regression F1 0.889
EXERCISE 2ML candidate worth further validation
GROUPED HOLDOUT32 rows / 8 unseen designs / 0 shared groups
FILES2 notebooks / 2 CSVs / runner / outputs / verifier

Exercise 1 exposes direct-label leakage. Exercise 2 uses noisy proxies and a hidden synthetic reference, but still cannot estimate hardware performance or approve a model.

LEARNING PATH / 00–07

Move from a table to a bounded engineering conclusion.

Each module names the decision and the artifact you should carry forward.

  1. 00

    Frame the engineering decision

    Name the target, grouping unit, error consequence, and simplest rule that could solve the task.

    OUTPUTDecision brief + rule baseline

  2. 01

    Define the dataset contract

    State what one row and one design represent, where each quantity came from, and its unit.

    OUTPUTSchema + design_id

  3. 02

    Detect direct-label shortcuts

    Check whether a feature contains or exactly reconstructs the target before treating performance as learned transfer.

    OUTPUTLeakage audit + USE RULE decision

  4. 03

    Prevent design leakage

    Keep every operating point from one design in one partition and fail if any design_id crosses the boundary.

    OUTPUTGrouped split + overlap check

  5. 04

    Compare rule, reference, and model

    Evaluate each method on the same held-out rows; complexity must improve the decision, not merely a score.

    OUTPUTFrozen comparison

  6. 05

    Read the critical error trade-off

    Inspect precision, recall, F1, support, balanced accuracy, and the confusion matrix.

    OUTPUTFalse-negative / false-positive review

  7. 06

    Test complete unseen designs

    Freeze the pipeline and evaluate on design groups withheld from training.

    OUTPUTHeld-out result + scope

  8. 07

    Define refusal and next evidence

    Record missing physics, unfamiliar inputs, validation still required, and when the system returns UNKNOWN.

    OUTPUTBoundary + further-validation plan

CHECK UNDERSTANDING

Prediction before explanation. Plan transfer after the worked example.

The core route is complete when you can explain the split, result, and boundary. Transfer to a second authorised dataset is a separate extension.

Why should exercise 1 use the rule instead of ML?

Because the target is exactly vout_min_v < 4.90 V. The explicit rule reproduces it perfectly; logistic_regression adds an error and no decision value.

Why would a random row split overstate performance?

Because related rows from one design can appear in both partitions, allowing the model to exploit design identity instead of transferring to an unseen design.

Why is accuracy insufficient here?

The majority NORMAL class can dominate accuracy while the critical COUT_TOO_LOW class is missed. Critical recall and the confusion matrix expose that failure.

What does the verified notebook result prove?

Only that the package reproduces two frozen synthetic decisions: use the exact rule in exercise 1, and continue validating the ML candidate in exercise 2. It does not prove causal diagnosis, transfer, or safety.

COMPLETION CRITERIA

  • Explain what one row and one design group represent.
  • Explain why the exact rule is preferred to ML in exercise 1.
  • Reproduce both decisions from the pinned environment.
  • Explain why the split prevents design leakage.
  • Identify the error that matters for the stated decision.
  • State one conclusion supported by the result and one that remains UNKNOWN.
  • State what additional authorised dataset and evidence would be required before attempting transfer.