Introducing the N.White Practical AI Operations Lab

#1
by nwhite-systems - opened

Operational AI is not only a model-selection problem. A request has to be understood, routed into an appropriate workflow, checked against permission and safety boundaries, reviewed by the right person and recorded with enough evidence to support correction later.

I built the N.White Practical AI Operations Lab as a small, inspectable demonstration of that control path:

request input → classification → workflow selection → human review → audited output

The lab is a dependency-free Static Space. It does not call a paid endpoint or external inference service. Visitors can filter enterprise use cases, examine responsible-agent scenarios, reveal expected and prohibited behaviours, and classify a non-sensitive operational request locally in the browser.

Three connected synthetic datasets

The interface brings together three versioned datasets:

  1. N.White AI Operations Intent Dataset contains 192 English-language requests labelled across eight intents: workflow automation, document processing, analytics, knowledge retrieval, exception handling, human escalation, API integration and reporting. Its deterministic splits contain 128 training, 32 validation and 32 test records.

  2. African Enterprise AI Use Cases contains 144 planning examples across insurance, education, mining support services, media, creative industries, non-profits, professional services and local commerce. Every example includes a human owner and safeguards. The expected benefits are hypotheses, not measured outcomes.

  3. Responsible Agent Workflow Evaluation contains 130 scenarios across 13 safety categories. It is intended for red-team and formative evaluation, with written criteria for expected safe behaviour and explicitly prohibited behaviour. It is not a safety certification or a universal automated benchmark.

Every record is synthetic. No client, customer, employee, learner, policyholder, claimant, beneficiary or production-system record was used. The examples were generated offline from authored matrices and validated for schema, counts, duplicate identifiers, file equivalence, privacy indicators and credential-like patterns. Synthetic data reduces disclosure risk here, but it does not remove bias, representativeness or governance concerns.

A genuine lightweight classifier, with a narrow evidence boundary

The N.White AI Operations Intent Classifier is a real scikit-learn pipeline: word-level TF-IDF unigrams and bigrams followed by multinomial logistic regression. It uses no pretrained base model and requires no network call for inference.

It was fitted once on the 128-record training split. On the 32-record validation split it achieved 1.0000 accuracy, 1.0000 macro F1 and 1.0000 weighted F1. The same three metrics were 1.0000 on the separate 32-record test split, with four test examples per class. After the saved joblib artefact was reloaded, eight separately worded smoke requests — one per class — were classified as intended. The exported browser parameters were also checked against the joblib pipeline.

Those results are genuine, but the evidence boundary is narrow. The full corpus has only 192 records, is balanced by construction and uses a shared deterministic authoring framework with clear intent-specific language. The model has not been evaluated on real operational traffic, code-switching, African languages, speech transcripts, ambiguous multi-intent requests, adversarial text or changing data distributions. Its class probabilities are uncalibrated, and it has no production abstention threshold. A perfect synthetic score shows that the packaged pipeline can learn and reload this demonstration task; it does not establish real-world accuracy, fairness or production readiness.

What responsible use means in this lab

The classifier output is a routing suggestion, not a decision. The lab is not suitable for insurance, credit, financial, employment, education, legal, medical or safety determinations. Visitors should enter only non-sensitive examples.

The wider workflow pattern keeps four requirements visible:

  • Privacy: minimise input data and keep confidential records within an approved, governed environment.
  • Permission: give tools only the authority required for the specific task; retrieved text and prompts remain untrusted input.
  • Human oversight: route consequential, uncertain or exceptional work to a named owner with a usable override.
  • Auditability: preserve sources, decisions, approvals and necessary traces so that an outcome can be reviewed and corrected.

The safety scenarios reinforce an additional point: a cautious-looking written answer can still conceal unsafe tool calls. Evaluation should inspect actions and traces, not only prose.

Explore the release

Next development steps

The most useful next steps are to build an independently authored test set, add misspellings and multi-intent requests, explore code-switching and locally reviewed African-language examples, evaluate calibrated abstention and compare human-review costs across error types. For the safety scenarios, I also want to add transparent reviewer-agreement guidance and test complete tool traces in isolated environments without credentials or mutation-capable production access.

I welcome reproducible documentation corrections, missing safeguards and locally grounded evaluation suggestions. Please do not submit private records, credentials or client information in public discussions.

Sign up or log in to comment