Profile
Regulated-platform and AI systems leadership grounded in operating reality.
My career has followed a consistent pattern: understand the system deeply, make the work visible, reduce ambiguity, automate what should be deterministic, and apply Artificial Intelligence (AI) only where it creates governed leverage.
The path started in electronics, communications, calibration, and fault isolation, where reliability was not a slogan. That discipline carried into Windows, UNIX/Linux, storage, backup, server-room, endpoint, manufacturing, laboratory, validated operational environments, and now context-governed AI systems.
Signal foundation
Signal foundation
Military electronics and communications shaped the way I think about systems. Signal quality, calibration, acceptable operating ranges, disciplined troubleshooting, and fault isolation became the foundation for how I approach infrastructure, automation, operational technology, and AI.
Hands-on systems engineering
Hands-on systems engineering
Before service ownership and product leadership, there was hands-on work: Windows, UNIX, Linux, network administration, storage, backup, cabling, server rooms, migrations, endpoint platforms, and the physical realities behind production and laboratory systems.
Life-sciences labs, manufacturing, and OT
Life-sciences labs, manufacturing, and OT
My regulated technology background spans manufacturing floors, quality laboratories, research and development environments, instrument-connected systems, Human-Machine Interfaces (HMIs), Manufacturing Execution System (MES) support context, validated software migrations, and ISA-95 manufacturing and enterprise-control model aligned manufacturing and enterprise-control environments.
Quality-system execution
Quality-system execution
I do not separate technical delivery from the quality system around it. Regulated work has to survive the Software Development Life Cycle (SDLC), Standard Operating Procedures (SOPs), work instructions, Nonconformance (NC), Corrective and Preventive Action (CAPA), audit trails, managed service handoffs, and inspection-aware questioning.
Service, product, provider, and people leadership
Service, product, provider, and people leadership
The operating model is global and cross-functional: service ownership, product ownership, vendor governance, Managed Service Provider (MSP) execution, Level 1 (L1) and Level 2 (L2) operating models, people leadership, service industrialization, stakeholder communication, and matrixed delivery across engineering, operations, quality, security, suppliers, and business teams.
AI as a built operating model
AI as a built operating model
I use AI as an operating tool, not a decorative feature. That includes coding-agent workflows, local and cloud inference, agent tuning, context management, retrieval-oriented systems, databases, vector stores, authentication, object storage, and deployment patterns. The goal is not to bolt AI onto everything. The goal is to build systems where AI improves speed, synthesis, and leverage while governance, evidence, and deterministic controls stay intact.
Learning by interrogation, not abstraction
Learning by interrogation, not abstraction
I do not learn complex systems from the wrapper first. I learn by working directly with the system: testing behavior, probing boundaries, finding failure modes, and turning discovered patterns into repeatable operating discipline.
That is how I approached AI. The focus was not prompt tricks or tool loyalty. It was model behavior, context management, branching workflows, memory portability, agent control, retrieval patterns, local and cloud inference, and the governance needed to make the work durable.
Context as code
Context as code
malott.ai is not only a public CV. It is a working pattern: context managed like code, with version control, validation, receipts, publishing discipline, and explicit public boundaries. The site demonstrates the operating model behind the words.
Public evidence library
Where the work lives
SharePlane is my public evidence library for finished artifacts: technical explainers, source-derived teaching pieces, operating models, reflective work, patterns, calculators, and other public-safe material worth preserving. The topic can change. The discipline does not: provenance, claim posture, receipts, metadata, and validation.
Receipts beat vibes.