I take concepts and complex problems from inception to working systems. I develop and challenge the architecture before implementation, anticipate engineering limitations and refine the design as new constraints emerge. My work spans sophisticated AI systems, intelligent autonomous technologies, software and physical engineering. I use AI as both a foundational system technology and an engineering multiplier, retaining responsibility from original concept through development, integration and validation.
Enterprise computing · business systems · physical and performance engineering · intelligent autonomy
One engineer. Multiple AI systems. One accountable architecture.
I use multiple AI systems as specialized engineering resources across research, rapid domain acquisition, architecture, implementation, code development, review, debugging and validation.
I frame and decompose the problem, assign bounded work across different AI capabilities, compare conflicting outputs and integrate what survives review. I evaluate executable behavior and retain responsibility for architecture, validation and release decisions.
01 / FRAMEDefine the system
Translate an unclear objective into interfaces, constraints and testable work.
02 / DIRECTAssign bounded tasks
Use distinct AI capabilities across research, engineering and review.
03 / RECONCILEChallenge outputs
Resolve conflicts against evidence, governing constraints and system design.
04 / INTEGRATEOwn the result
Connect components, exercise behavior and decide what may advance.
1 architect · multiple AI engineering resources orchestrated in parallel · 2 intelligent autonomous system architectures · end-to-end ownership
The AI engineering resources are separate from the runtime models in either product. The products bring interpretation, bounded decisions and action, observation and evidence updates into governed workflows.
FLAGSHIP PUBLIC ENGINEERING
Working public demonstrator
V.I.R.A.L.™ Motorsport
Vehicle Intelligence Reference Architecture Lab™
Beyond the Boundaries of Vehicle Telemetry.
A new frontier in AI-driven vehicle engineering intelligence, transforming how performance, degradation, limitations and opportunities are understood across motorsport and road vehicles.
V.I.R.A.L.™ Motorsport is a working public demonstrator for continuous vehicle engineering intelligence, connecting pre-failure awareness, probabilistic diagnosis, bounded preservation, condition-based maintenance, engineering improvement, design requirements and post-modification validation.
Detect developing limitations before obvious performance loss or conventional hard thresholds.
ENGINEER
Diagnose likely causes, identify condition-based maintenance needs and rank engineering responses or upgrades by modeled benefit and tradeoff.
DESIGN
When no available solution satisfies the engineering constraints, define what the new component or system needs to accomplish.
VALIDATE
Repeat comparable operating conditions after a modification and determine whether the original limitation was solved or the bottleneck simply moved elsewhere.
Control effort: 15.73% → 8.18% · Tracking error: 0.141 bar → 0.093 bar · Minimum engineering margin: 0.58 → 0.76 · Replacement bottleneck: none detected
Synthetic public demonstration values.
The same architecture can scale across elite motorsport, OEM development, specialist performance engineering, club racing and advanced enthusiast applications, with deployment-specific data depth, models and authority.
Experience a working synthetic demonstration of how V.I.R.A.L.™ converts whole-vehicle operating data into engineering understanding, prediction, bounded response and validated learning.
Two intelligent autonomous system architectures show the method in practice: interpreting changing inputs, advancing bounded work, observing results and deciding what the evidence can support.
Project 01 / intelligent autonomous product system
Integrated working candidate
Intelligent, bounded autonomy in a product system.
One architect connected specialized AI roles, a TypeScript/Vite application, live external services, analytics and controlled workflows into a functioning system. It interprets intent and context, generates candidate work, evaluates meaning and policy, then advances authorized actions through controlled execution, observation and repair paths.
What was built · engineering surface
Multi-model orchestration · MCP/API discovery and interfaces · TypeScript/Vite application · external data and analytics · semantic/policy validation · approval routing · controlled execution · observability · repair workflows
I independently architected, built and integrated the candidate, directing AI capabilities as engineering resources while retaining the system and release decisions.
The engineering problem
Several capable models and tools can still produce a fragmented or unsafe product. The system needed context-aware handoffs, consistent state and an explicit boundary between recommendation and action.
Architectural decisions
I separated read, review and execution authority, used live interface discovery to connect outside services and made connector failures and malformed inputs visible for repair. A dry run can exercise the execution path without making an external change.
Where intelligence lives
At runtime, specialized model and tool stages interpret context and produce candidate work. Validation checks meaning and policy; deterministic controls and human authorization govern external changes.
38 / 38
Focused offline checks passed after an evidence-source defect was repaired without weakening the gate. Broader regression was incomplete, so the candidate remained unpublished. The result establishes focused offline verification only.
Architecture and release investigation · Project 1
01Intent & contextInterpret the request and assemble relevant state.
02Role orchestrationRoute work among specialized AI and tool capabilities.
03Candidate workGenerate a proposed result or external operation.
04Semantic & policy reviewCheck meaning, constraints and readiness before action.
05Authorized executionApply only permitted changes and retain an outcome record.
Authority boundaryModel output does not grant permission. External changes require the designed approval path and a controlled connector; rejection or failure returns the workflow for correction.
Technical architecture · Project 1
External interfacesLive MCP/API discovery connects outside services, data and analytics to application state.
AI workSpecialized model and tool stages interpret context and prepare candidate outputs.
GovernanceSemantic and policy checks lead to a separate approval path before consequential operations.
Controlled executionDry runs exercise the path without external mutation; failures surface as repairable states.
Release investigationselect a finding
A stale evidence binding blocked readiness.
The gate identified that identity evidence attached to the candidate did not reflect the current verified source. Advancing without repairing the binding would have made the release record unreliable.
Why this is a systems problem, not a green-check problem
The gate did more than count checks: its value depended on the provenance and freshness of evidence bound to the candidate. The correction preserved the gate's standards, repaired the evidence chain and then held release because the broader test picture was incomplete. That is the difference between a pass indicator and an operational decision.
Project 02 / intelligent autonomous decision system
Runtime and prospective validation architecture
An intelligent autonomous decision system built end to end.
I built an operating path that interprets live conditions, constructs market state, generates signals, applies execution and risk gates, connects to broker and order lifecycle infrastructure and records persistent evidence for replay and prospective evaluation. The engineering significance is the integrated, inspectable system.
What was built · operating architecture
Live data → market state → signals → execution gates → broker interface → orders/fills → lifecycle → reconciliation → diagnostics → persistent telemetry → offline replay → prospective validation
Runtime, broker state and an independent evidence path are connected without granting the validation observer order-placement or policy-promotion authority.
I independently architected and built the data-to-execution chain and its validation infrastructure, including the controls that determine whether a candidate can advance.
THE HARD PROBLEM AND DECISION
Make the evidence worthy of the system.
A promising historical result failed timing integrity controls. I rejected promotion rather than tuning around the failure, froze the policy and built a forward-only observer to collect genuinely prospective evidence.
Freeze the policy. Observe forward. Never write yesterday's evidence today.
14 tests
Prospective observer control suite passed. This verifies observer behavior, not strategy effectiveness. Policy promotion and external execution remain disabled in that lane.
Technical architecture · Project 2
Runtime pathMarket data becomes state and candidate signals before execution gates inspect exposure and broker state.
Order lifecycleBroker interfaces, order and fill events, reconciliation and diagnostics maintain an inspectable execution record.
ValidationReplay, chronological splits, friction and leakage checks challenge retrospective results.
Prospective laneCompleted data enters an append-only observation stream under a frozen policy, isolated from order placement.
Prospective validation investigation · evidence and controls
Excerpted fields from a dated operator continuity record for the prospective observer. This snapshot shows observation without external execution; it does not establish policy performance.
Prospective evidence path · observation mode
01 / AVAILABILITYWait for completed data
Use official session data only after its stated availability window.
02 / ELIGIBILITYEnforce time & date
Capture only the current eligible observation; reject stale input.
03 / INTEGRITYAppend, don't rewrite
Preserve ordered evidence and detect changes to prior records.
04 / MATURITYEvaluate when due
Record later outcomes against the frozen policy and its assumptions.
Current authorityProspective observation and simulated exposure only. Backfill, policy promotion and external execution remain disabled.
Why the method changedselect a decision
The historical result did not clear the timing controls.
A strong-looking retrospective result was insufficient because the evaluation failed its circular-timing checks. The candidate was rejected for promotion rather than explained away.
What this demonstrates about autonomy
Autonomy is a workflow property: the observer is designed to advance eligible records through capture, integrity checks and outcome maturity without a person directing each transition. Its authority is deliberately narrow. It cannot repair missed history, change the frozen policy, promote a signal or execute an external action.
PUBLIC ENGINEERING
Bounded Agentic Execution Architecture
A public reference implementation demonstrating how intelligent autonomous systems can reason, select tools and execute actions while remaining inside explicit authority, validation and observability boundaries.
Engineering evidence
Explicit authority levels and execution boundaries
Human approval gates for consequential actions
Controlled tool execution
Pre-execution and post-execution validation
Evidence and audit logging
Failure escalation rather than silent authority expansion
Synthetic authority-control demonstration
Automated regression testing
Passing GitHub Actions CI
Purpose
Demonstrates the control architecture required to move beyond AI generation and recommendation toward useful, accountable autonomy without exposing proprietary systems or private implementation details.
My technical history began in professional computer engineering in London, supporting mission-critical technology for major global investment banks, including trading-floor and executive systems. Across more than two decades, I’ve also built a regulated business from the ground up, implemented physical infrastructure, engineered performance vehicles and architected intelligent autonomous systems. The domains changed; the method remained: understand the complete system and make it work.
Enterprise computing
Trading-floor and executive technology, systems failures and integrated support.
Business systems
A regulated clinic built from zero across facilities, technology, staffing and operations.
Physical engineering
Electrical and electronic systems, infrastructure and practical implementation.
Performance engineering
Vehicle dynamics, thermal behavior and validation under real operating conditions.
Intelligent autonomy
Contextual reasoning, multi-model orchestration, bounded execution and evidence feedback.
Where I create value
Problems that need a whole-system view.
The evidence spans vehicle engineering intelligence, controlled AI product workflows and autonomous decision systems. Each connects a governing problem to architectural choices and executable validation.
01 / UNDEFINED PROBLEMS
Give the outcome a system shape
Project 1 took product intent through requirements, interfaces, a working application and release controls.
02 / CROSS-DOMAIN PROBLEMS
Connect what separate teams see
Across both projects, product, external services, software, data, execution and validation became one accountable architecture.
03 / HIGH-AUTONOMY PROBLEMS
Give intelligence accountable limits
Both projects show intelligent autonomy that interprets, decides and advances meaningful work inside engineered limits, evidence controls and accountable authority.
Most valuable where complexity spans teams, technologies or domains and the organization needs one accountable architecture from ambiguous objective through working system.
PythonFastAPITypeScriptViteGitPowerShellAPIsMCP
Implementation vocabulary, secondary to the project evidence.
Relevant Technical Mandates
Principal AI Architect · AI Systems Architect · Agentic AI Architect · Enterprise AI Architect · AI Solutions Architect · AI Systems Engineer · Technical Product Architect
Next challenge
Give me the problem that doesn't fit neatly inside one discipline.
I work with organizations developing new products, exploring advanced engineering capabilities or confronting problems that have yet to become defined specifications. I bring original systems architecture, multidisciplinary engineering and complete development responsibility to the challenge.
Available for senior engineering positions, independent contracts, consultancy and strategic technical collaborations worldwide.
