Founder of YOSO-YAi | Systems Architect
Mechanical. Electrical. Controls. Compute.
I build intelligent infrastructure from power to autonomy.
My path runs from pulling wire and bending conduit to instrumentation, controls, mission-critical construction, embedded hardware, private AI infrastructure, and company-level systems architecture. I have spent more than twelve years learning how physical systems are installed, commissioned, maintained, and trusted in the field.
The same discipline that produces a readable electrical panel produces a managed compute rack, a bounded control loop, a battery failover system, and an auditable AI workflow. The physical and digital are the same craft applied at different scales.
- Industrial electrical: field work across petrochemical, LNG, and infrastructure projects; conduit, raceway, power distribution, prints, installation quality, and safe handoff.
- Instrumentation and controls: sensor integration and PLC-oriented control work at Tesla's Gigafactory, connecting electrical power to measurement, logic, and controlled action.
- Mission-critical leadership: electrical foreman work on Meta's NightCrawler hyperscale data-center program, coordinating crews and quality where documentation, uptime, and failure prevention matter.
- Systems architecture: electrical, mechanical, embedded, software, data, and AI infrastructure brought together under one controlled architecture.
- Founder: building YOSO-YAi around the company line, the future of labor is compute.
The field taught me to ask whether a design can be installed, labeled, tested, serviced, and understood by the next qualified person. Those questions still govern the systems I design now.
YOSO-YAi develops autonomous systems that turn compute into controlled professional and operational capacity.
- YOSO-YAi Worker: profession-specific, privately controlled compute systems organized around real workflows, accepted deliverables, measurable outcomes, and human authority.
- ASU and ASUB: a mobile site-control service and company-owned field service assets for mission-critical work.
- YOSOR: a hardware-development operations platform for requirements, decisions, risks, reviews, evidence, and release handoffs.
- SYSTM: bounded facility-control architecture connecting normalized sensing, approved deterministic execution, controlled actuation, interlocks, fail-safe behavior, and human approval.
- Internal engineering factory: the 12U rack, Full Power Rack Intelligence Board, worker nodes, telemetry, orchestration, Data Factory, dataset, and evaluation workflows used to build and prove the larger system.
These are active engineering and product-development lanes, not claims that every system is released, deployed, or commercially available.
- field-to-architect - the career arc from field craft to cross-discipline architecture.
- electrical-panel-dressing
- conductor routing, labeling, commissioning, and as-built discipline.
- mission-critical-discipline
- lifecycle, maintainability, failure review, and trusted handoff.
- public-pcb-review-checklist
- schematic, power-domain, interface, evidence, and fabrication review.
- pico2-pio-i2c-reference
- RP2350 and PIO-oriented embedded architecture reasoning.
- s2h-g-control-ledger
- simulation-first control doctrine, fault handling, and energy accounting.
- Electrical and controls: power distribution, instrumentation, sensors, PLC-oriented logic, panel discipline, commissioning, and field handoff.
- Embedded hardware: KiCad, PCB architecture, Raspberry Pi, RP2350, firmware boundaries, power, thermal, sensing, and actuation.
- Mechanical systems: Fusion 360, rack geometry, enclosure design, mounting, airflow, serviceability, and physical integration.
- Software and data: Python, TypeScript, Linux, Docker, APIs, telemetry, logging, orchestration, data pipelines, and evaluation tooling.
- AI infrastructure: NVIDIA DGX, local inference, private data handling, dataset preparation, fine-tuning handoffs, evaluation, and agent workflows.
- Engineering operations: requirements, interfaces, decisions, risk, evidence, verification, release boundaries, and source control.
- Start with physical and operational reality.
- Treat field constraints as architecture inputs, not afterthoughts.
- Make interfaces, ownership, authority, and failure boundaries explicit.
- Review failure modes before they become field surprises.
- Separate concepts, prototypes, evidence, validation, and release claims.
- Build records that another qualified person can inspect and trust.
- Keep private company source in Forgejo and publish only reviewed, public-safe work here.