# Industrial AI: an interview and learning guide

This portfolio now demonstrates three different kinds of work: a fitted sensor classifier, local language-model generation, and a model-directed read-only tool loop. Present them as new inspectable implementations built for this portfolio. The manufacturing clients remain confidential. The user reports paid OpenAI and Google Gemini API use for client delivery and experience with Microsoft-provided corporate AI services; original client source, exact model versions and instruments remain unspecified. Local Qwen is the current demonstration runtime.

## A clear role introduction

“I’m interested in AI implementation and solutions engineering. I like understanding an operating problem, choosing where a model actually helps, connecting it to reliable data and tools, and building the review workflow around it. My portfolio lets me demonstrate those choices with measured industrial recordings, a trained classifier and a local tool-calling assistant.”

This describes practical implementation strengths. It does not require claiming deep research expertise, a novel learning algorithm, paid adoption or production outcomes that have not been established.

## Keep the three layers distinct

| Layer | What happens in this implementation | What it proves |
| --- | --- | --- |
| Supervised ML | Python/NumPy fits regularized logistic coefficients from measured sensor features and recorded pump-leakage labels | A reproducible training/evaluation pipeline and browser inference from learned parameters |
| Generative language model | An existing `qwen3.5:latest` model runs locally through Ollama and LangChain `ChatOllama` | Actual model inference and generated investigation prose; the language model was not trained here |
| Read-only tool agent | The language model requests bounded evidence tools; server code validates arguments, executes them and returns receipts to the model | Model-directed evidence lookup/computation with observable tool calls, limits and human review |

The sensor classifier answers a binary classification question about a recorded cycle. The language model drafts an explanation. The tool loop connects that draft to inspectable evidence. None of those layers establishes a physical fault cause or authority to change a machine.

## Explain the fitted ML experiment

**The task.** Distinguish cycles labelled with weak or severe internal pump leakage from cycles labelled with no leakage. The target is original `profile.txt` column 3: zero versus greater than zero. This is binary end-of-cycle classification, rather than severity estimation or early failure prediction.

**The source.** The [UCI hydraulic dataset](https://archive.ics.uci.edu/dataset/447/condition+monitoring+of+hydraulic+systems) contains measured repeated 60-second test-rig cycles with controlled component conditions. The full original archive supplies PS1 pressure, EPS1 motor electrical power, FS1 volume flow, TS1 temperature and VS1 vibration velocity. It is attributed public research data under CC BY 4.0, not either client's production telemetry. See `hydraulic-data-provenance.md` for source context and `scripts/train-hydraulic-ml.py` for the experiment.

**The representation.** Each signal contributes six predetermined features: whole-cycle mean, within-cycle population standard deviation and four 15-second phase means. Thirty sensor-derived values enter the model. Profile labels, stability flag, source row ID and the other recorded component labels do not enter that vector. Other labels can be inspected afterward as experimental context.

**The split and scaler.** Seed 42 creates separate random permutations of the two target classes; 25% of each class, rounded upward, is held out. That produces 1,653 training rows and 552 held-out rows. Standardization uses only training-row means and population SDs. The held-out rows do not fit the scaler or the coefficients.

**The estimator.** A NumPy full-batch gradient implementation minimizes mean binary cross-entropy plus an L2 coefficient penalty of 0.01/2; the intercept is not penalized. Feature definitions, penalty and decision threshold 0.5 were fixed before the run. A training-data Lipschitz bound sets the descent step. The optimizer reached its gradient tolerance in 4,307 iterations. This is an interpretable baseline using a familiar method, not a new algorithm or a trained LLM.

**The measured result.** The recorded held-out result is:

| Measure | Fitted classifier | Training-majority baseline |
| --- | --- | --- |
| Accuracy | 97.28% | 55.43% |
| True positives / true negatives | 231 / 306 | 0 / 306 |
| False positives / false negatives | 0 / 15 | 0 / 246 |
| Leakage recall | 93.90% | 0% |
| F1 | 0.96855 | 0 |
| ROC-AUC | 0.99922 | 0.5 |

The majority prediction is selected from training labels and applied unchanged to the same held-out rows. All 15 classifier misses are weak-leakage-labelled cycles in this split. That observation is inspectable; it does not prove why the model missed them. Original row 390 is one example: its leakage score is about 44.84%, below the fixed 50% threshold, although the recorded target is weak leakage.

**The limit to say immediately.** This is a random split from one rig. Adjacent cycles and repeated conditions can be correlated across the split, making performance optimistic. It is not evidence of temporal, grouped-condition, unseen-machine or client-plant generalization. The full 60-second cycle is used; probabilities are not independently calibrated. Correlated feature coefficients explain model associations, not physical causes. A future validation plan would hold out complete condition runs, later periods and eventually a separately reviewed machine dataset.

**The implementation proof.** The JSON artifact retains row identities, source checksum, feature fingerprints, training scaler, coefficients and every held-out feature vector/prediction. TypeScript reproduces all 552 Python predictions; tests independently recompute confusion and rank/trapezoid ROC metrics. Running the training script again produced a byte-identical artifact. Explain these checks as numerical and data-pipeline verification, separate from field validation.

## Explain the local language model and tool loop

“I used an existing local Qwen model through Ollama and LangChain. I supplied bounded tool schemas for recorded-cycle lookup, measured phase comparison, curated reference search and held-out classifier inference. The model selects a tool; server code validates its arguments and executes the permitted read-only calculation. Its receipt goes back into the conversation before the model drafts a brief.”

The code is in `src/lib/operations-agent.ts` and the localhost API route. Tool outputs preserve measured differences, experimental labels, classifier results and source IDs as separate evidence. `reference_search` matches terms in a small set of curated summaries of cited UCI/HYDAC/Parker material. It is not an unrestricted web search, a private-manual collection or an embedding/vector database.

The loop records model-call timing/token metadata, requested tool inputs and returned receipts. It limits context, output, calls and duration. Citation validation checks whether source identifiers were supplied by actual tools; it does not establish paragraph-level truth. A fluent answer can still be incomplete or wrong, so the result is a draft for human review.

The model cannot issue machine commands, approve purchases, send messages or read BricDesk records. A requested client incident without a recording must remain unsupported, rather than being replaced with a convenient public example. See `local-ai-runtime.md` for startup and operational boundaries.

## A practical demonstration sequence

1. Open MachineScope and explain that its recordings come from the public test rig. Show the source row, rate/unit and phase-aligned comparison.
2. Open the learned-model study. Compare it with the majority baseline and inspect an actual false negative before showing coefficients.
3. Show the timing/feature equation for a held-out row. Distinguish the learned score from the recorded label and a maintenance diagnosis.
4. Ask the local assistant to inspect a named public cycle or held-out row. Read the actual tool trace and citation receipts alongside its generated draft.
5. Try an unavailable client recording. The missing evidence should be visible; do not treat a failed, truncated or unsupported draft as success.
6. Export the evidence/experiment or generated draft with its scope and review state. Nothing should be sent to an operator or changed on a machine.

The authored model-evaluation script defines positive evidence requests and negative cases for unavailable sources, fabricated citations/action claims and unauthorized BricDesk actions. Read its saved attempts and final results before describing an outcome. Automated checks and eight authored prompts are not a field accuracy or robustness certification.

## Quantitative thinking for a useful solution

Accuracy is only one check. Ask how costly missed events and unnecessary checks are for the operator. Compare against a simple baseline; examine recall, false negatives, false positives, subgroup conditions and the actual error examples. Separate missing data, measurement quality, unusual behaviour and confirmed faults.

For a future pilot, choose success measures before looking at results: source completeness, reviewer time, proportion of drafts usable after correction, missed reviewed events, nuisance-review burden and whether operators can trace a recommendation to evidence. Report numerator, denominator, time period and exclusions. Do not convert this rig benchmark into a prediction of factory savings.

## A narrow monetization pilot to validate

The potential customer is a maintenance or production lead who already has trustworthy cycle readings and spends time assembling investigation context. This is a customer/problem hypothesis, not established demand for this portfolio tool.

Start with one machine group and one review decision: assemble a cycle comparison and source-backed investigation brief. Obtain permission for the supplied data, document the signals and timing, agree which operator reviews it, and preserve a manual path. The first delivery could be a bounded implementation service: source intake, data checks, baseline comparison, reviewed brief/export and a limited operator trial. Price and continuation should be discussed with a real buyer after the scope, review workload and value are understood; no unsupported price or savings figure is needed.

A useful pilot gate is that the recipient can supply the inputs, reproduce the finding, correct the draft and decide the next inspection without an automatic machine action. Stop or revise the model if data quality or error burden makes that workflow unreliable. A paid pilot, recurring fee or broader product should follow evidence of use and willingness to pay, not the presence of an AI label.

For BricDesk, a later assistant would need its own authorized data access and workflow context. Read-only explanation might help someone understand inventory or an approval trail. Holds, approvals and messages require explicit project/record identity and appropriate user authority; the current industrial agent is not connected to those actions.

## Answers to common interview questions

**“What did you train?”** “A regularized sensor-feature logistic classifier on attributed public hydraulic recordings. I used an existing Qwen language model for local inference; I did not train or fine-tune that language model.”

**“What is agentic here?”** “The model selects bounded evidence tools in a loop. I can show the native tool requests, validated inputs, executed receipts and the generated draft. The tools are read-only and have no machinery or messaging capability.”

**“Why this baseline?”** “Its representation, scaler and coefficients are inspectable. It gives me a numerical reference before proposing a more complex model. The errors and the weak same-rig split tell me what validation is still missing.”

**“What is your contribution?”** “Problem framing, data and tool boundaries, feature/training pipeline, orchestration, review interactions, source/metric verification and the handover. I’m strongest in connecting those pieces into a useful implementation.”

**“Was this deployed at your clients?”** “These are new portfolio implementations. My earlier client work included solar configuration and sensor-based manufacturing anomaly work, but its original source and exact historical stack are not available here. I keep that history separate from what I can demonstrate now.”

## Client delivery versus the public model demonstration

“Client AI automation and integrations used paid OpenAI and Google Gemini services. The public portfolio uses a local Qwen model through Ollama and LangChain so the evidence workflow can be demonstrated without a paid API key. Those are different delivery contexts; the current demo is not a copy of the original client deployment.”

Microsoft-provided corporate AI services can be discussed as reported experience without inventing an Azure product, model version, client attribution or performance outcome.

## Explain it simply and prepare cloud basics

For a short introduction to a nontechnical interviewer, begin with the operating problem, show one change in the demo and explain what a person can check. Then open the detailed model or data notes if they want to go deeper. See [interview-story.md](interview-story.md) for short project explanations and [cloud-interview-guide.md](cloud-interview-guide.md) for introductory AWS/Azure study. Learning the named cloud services does not establish past production use.