I build systems where software meets the physical world: scientific computing, embedded electronics, telemetry, signal processing, industrial diagnostics, data infrastructure, AI and cybersecurity.

At Rootcastle Engineering & Innovation, the work spans both scientific research and industrial engineering. The same project can move from a numerical model or experiment to a sensor interface, embedded target, network protocol, backend service, database, analysis pipeline and field deployment.

The focus is not one framework or one layer of the stack. I work across complete cyber-physical systems: sensing, embedded control, signal processing, protocols, backend infrastructure, scientific analysis and operator-facing software.

• Scientific computing, numerical methods and computational experiments
• Embedded systems, sensor interfaces and instrumentation
• Signal processing, vibration and machine-condition analysis
• IoT, GNSS, telematics and device protocols
• Backend systems, data pipelines and multi-tenant platforms
• Industrial software, automation and engineering tools
• Artificial intelligence and agent-assisted engineering
• Cybersecurity, threat modelling and defensive architecture
• Prototyping across PCB, 3D printing, CNC and mechanical integration

The language choice follows the system boundary rather than fashion: C/C++ and Assembly close to hardware, C#/.NET for engineering applications and services, Python/Julia/MATLAB for scientific work, TypeScript/JavaScript for web systems, and Java/Kotlin/Swift/Dart where platform constraints make them the right tool.

For critical software, my default engineering approach is influenced by defence and aerospace software discipline, NASA Power of Ten, MISRA-style constraints, safety-critical design and defensive systems engineering.

That means bounded behaviour where practical, explicit state transitions, narrow interfaces, input validation, least privilege, fail-safe defaults, typed failures, reproducible builds, requirements traceability, observability and a rollback path designed before deployment.

These are engineering influences, not blanket certification claims. Formal compliance is claimed only when a project explicitly documents and verifies it.

External systems / devices / users
              |
              v
      Adapter / Gateway
              |
              v
       Validation boundary
              |
              v
        Core domain logic
          /    |     \
         /     |      \
  Storage  Observability  Integrations

New integrations should adapt to the core. The core should not repeatedly mutate around external systems.

A feature is not complete because it compiles or because a happy-path demo works. I want to know what happens when input is malformed, a dependency disappears, the network becomes unreliable, the process restarts, latency grows, a sensor drifts or an operator does something unexpected.

The useful questions are operational:

Can we detect it? Can we reproduce it? Can we contain it? Can we roll it back? Can we prove the fix?