Skip to main content
← Back to Articles

Building Meshesha Solutions: Our Applied Research Journey, 2025–2026

Yonas MesheshaYonas Meshesha•2026-10-20T12:53:36.939402Z•Development, Research, SBIR, Small-Business

From engineering decision intelligence to autonomous systems and mathematical optimization, a retrospective on Meshesha Solutions' early research efforts, federal R&D proposals, technical lessons, and the road ahead.

Founded in May 2025, Meshesha Solutions LLC is an independent research and development company focused on artificial intelligence, mathematical modeling, optimization, and engineering software.

Over the past year, we have pursued a range of technical directions through independent study, computational experimentation, and proposals to federal R&D programs, including the Small Business Innovation Research (SBIR) and xTech programs. While our federal submissions have not yet produced an SBIR award, they have produced detailed technical architectures, rigorous external evaluations, and sharp questions about where our approaches are credible and where our evidence needs to improve.

Different proposals received very different assessments:

  • One architecture was rated highly acceptable for technical sufficiency and commercialization, yet went unfunded in a competitive pool.
  • Another received praise for its state-of-the-art co-design stack while raising fair questions about integration risk, training-data fidelity, and domain coverage.
  • Others challenged us to look past algorithm performance on academic benchmarks and prove how an estimator or sensor model translates into dependable field operations and maintainer workflows.

We are sharing this retrospective to document the problems we have investigated across five core efforts—ATLAS, SHADOW, ARBITER, Depot Doctor, and Grid Doctor—and how those lessons directly shape our current work in engineering decision assurance.


1. Governed Agentic AI for Cybersecurity (ATLAS)

One of our primary research directions investigates how language-model-based agents can assist with bounded cybersecurity workflows while operating within strict authorization and execution constraints.

Our proposed Autonomous Threat Lifecycle Agentic System (ATLAS) designed a Phase I assessment workflow around three core services: a Commander to organize tasks, a Scout to enumerate an authorized emulated network, and an Oracle to research vulnerabilities using linked evidence—reserving two additional interface and safety-gate agents for subsequent development.

Proposed ATLAS architecture showing authorized assessment boundaries, agent orchestration, read-only enumeration, knowledge-grounded research, and auditable reviewer output.

Figure 1. Proposed ATLAS architecture: bounded agent coordination and evidence review. The diagram outlines intended Phase I components and later expansion; it describes a proposed research design rather than a validated operational capability.

The central research question was not simply whether an AI agent could invoke security tools, but whether its behavior could be controlled, observed, reconstructed, and evaluated. Our experimental plan focused on measurable baselines: comparing graph-assisted retrieval against simpler retrieval methods, measuring valid findings against assessment cost, and testing whether delegated actions retained complete audit records.

Submitted to a Defense Logistics Agency (DLA) SBIR solicitation, ATLAS was rated highly acceptable for technical sufficiency and commercialization and acceptable for personnel qualifications, though limited program funding restricted awards to the highest-ranking submissions.

What we carry forward:

  • Separate proposal credibility from tested performance: A favorable technical review validates that our research questions and architecture are well-formed, but it does not substitute for executing the benchmarks.
  • The system assessing other software needs its own assessment boundary: In consequential workflows, an agentic system's authority limits, tool access, task recovery, evidence trail, and resilience to hostile inputs must be evaluated right alongside the quality of its findings.

2. Scientific Machine Learning and Multidisciplinary Optimization (SHADOW)

A second research direction explores integrating scientific machine learning with numerical optimization for complex engineering systems.

Our SPIKAN-Accelerated Hypersonic Analysis, Design, and Optimization Workflow (SHADOW) proposed bringing geometry, trajectory, and control into a concurrent engineering-design process. Its core research contribution centered on integrating separable physics-informed neural-network surrogates (using spline-based Kolmogorov–Arnold network methods) into a multidisciplinary optimization stack built on OpenMDAO, Dymos, JAX, and OpenFOAM.

External evaluation of the Navy SBIR submission recognized the all-at-once co-design architecture as state of the art, found the software stack technically sound, and noted strong defense-prime transition interest. At the same time, the review pinpointed concrete risks:

  1. Integration complexity: Embedding a research-grade learning method inside an already complex multidisciplinary design framework carries substantial execution risk.
  2. Training-data fidelity: Relying primarily on engineering-level models with a limited number of high-fidelity computational fluid dynamics (CFD) reference cases raises questions about surrogate accuracy across the design space.
  3. Domain coverage: Strong machine-learning and software engineering capability is distinct from demonstrated experience in hypersonic aerothermodynamics and trajectory optimization.

What we carry forward:

  • Sound architecture does not settle integration risk: Individually promising techniques and a modern software stack do not automatically guarantee a feasible end-to-end system at the required physical fidelity.
  • Domain judgment is a core technical requirement: In scientific machine learning, external domain specialists are not just additions to an organizational chart—they are essential to designing the training-data regime and judging whether the physical approximations hold.

3. Advisory Boundaries in Mission Systems (ARBITER)

We have also investigated decision-support algorithms where automated recommendations must coexist with strict human and system authority.

ARBITER (Adaptive Resource Brokering with Information-Theoretic Explainable Reallocation) addressed sensor resource allocation for naval self-defense environments. It proposed a modeling-and-simulation advisory layer designed to characterize existing sensor allocations and recommend adjustments within permitted operational constraints.

Rather than maximizing autonomy, ARBITER's defining architectural choices were its limits:

  • Preserving authoritative system priorities and protected functions at all times.
  • Requiring an inspectable audit record for every proposed reallocation.
  • Defaulting to no change: Retaining the existing allocation whenever underlying information is insufficient or a decision cannot be computed within the required time window.

What we carry forward:

  • A useful recommendation must state when it should decline to act: An internal model estimate alone is not sufficient grounds for claiming an operational improvement. Advisory systems must explicitly separate simulation assumptions from authoritative system state—and preserve the status quo when they cannot establish a sufficient basis for change.

4. Physics-Informed Diagnostics and Operational Fit (Depot Doctor & Grid Doctor)

Two of our Army-focused proposals applied physics-informed machine learning to hardware diagnostics and power monitoring: Depot Doctor and Grid Doctor. Together, they taught us our sharpest lessons about the gap between an algorithm's benchmark accuracy and a product's operational utility.

Depot Doctor: Algorithm Performance vs. Maintenance Workflow

Depot Doctor proposed combining battery-health estimation with low-touch storage and charging management for Army 6T lithium-ion batteries, uniting battery-management-system (BMS) telemetry, physics-informed models, and a maintenance interface.

While reviewers found the scientific feasibility satisfactory and the concept clearly communicated, they critiqued the competitive analysis, technical data support, and customer discovery. We had cited strong improvements from published machine-learning literature to argue for better battery maintenance, and we had treated the published solicitation topic itself as customer validation while deferring maintainer interviews to Phase I.

The takeaway: A published government need establishes relevance, not workflow fit. Likewise, showing that an estimator performs well on a research dataset does not by itself prove that it will reduce unnecessary battery replacements, improve storage decisions, or save maintainer effort on actual 6T telemetry.

Grid Doctor: Performance Gates vs. Inspectable Product Claims

Grid Doctor proposed adapting an Army Research Laboratory patent for non-contact power measurement—which uses both radial and tangential magnetic-field measurements around a cable to improve conductor-current estimation—into a commercial power-monitoring and cable-health product.

Feedback from the Army xTech competition credited our understanding of the source technology and adaptation roadmap, but challenged us on a fundamental point: we had not adequately explained the reliability of the final product or why a buyer would choose it over existing alternatives. Furthermore, from a sensing standpoint, recovering additional electrical quantities requires sufficient independent measurement information, and estimating physical parameters like cable twist is a separate research step from proving remaining cable life.

The takeaway: Internal R&D milestones and relative error-reduction targets do not tell a user what they are buying. A credible technical proposal must connect the algorithm to an inspectable product claim: the exact quantity being estimated, the operating conditions under which it can be trusted, the reference standard used to evaluate it, and the concrete advantage delivered to the operator.


5. Applying These Lessons: Engineering Decision Assurance

Every lesson from these five efforts converges in our current research focus: Engineering Decision Intelligence and Assurance.

In complex engineering programs, decisions depend on an interconnected web of requirements, trade-study preferences, analytical models, configurations, and human approvals. As a design evolves, an engineering recommendation can remain numerically unchanged even when its supporting assumptions no longer apply.

Consider a vehicle trade study carried through successive design reviews: added mass or a revised duty cycle might invalidate a thermal or cooling assumption without changing which propulsion option ranks first numerically. Simply reproducing the old calculation does not tell the program whether the conclusion remains a valid basis for approval.

Proposed engineering decision architecture separating agent-generated plans, human authorization, deterministic evaluation, release checks, and retained decision records.

Figure 2. Proposed engineering decision-assurance workflow. Agents draft structured plans, humans retain approval authority, and deterministic evaluators check the supporting basis before a decision package is refreshed or held. The diagram represents an active research design, not a validated claim of reduced analyst effort.

Building on the Decision Digital Thread schema and prior foundations in truth maintenance, model applicability, and set-based design, our proposed Decision-Assurance & Selective-Refresh Workbench separates three distinct questions:

  1. Reproducibility: Can the analytical computation be reproduced?
  2. Applicability: Do the supporting evidence and models still apply to the current configuration and operating assumptions?
  3. Governance: Does an earlier human approval remain valid after relevant upstream changes?

In this architecture, AI agents are restricted to drafting structured inputs and refresh plans, deterministic evaluators execute the calculations, and human engineers retain approval authority. Our planned evaluation compares selective refresh against a full trade-study rerun under shared controls—treating correctness as a strict acceptance condition and lower refresh effort as a testable hypothesis rather than an assumed result.


Building Our Infrastructure & Looking Ahead

To ensure our future proposals arrive with stronger baseline data and preliminary evidence, we have invested in our own independent computational infrastructure. Our local environment—built on Linux compute nodes, GPU acceleration, container orchestration, and self-hosted machine-learning and retrieval tooling—allows us to run reproducible benchmarks, test integration boundaries, and build working prototypes prior to solicitation deadlines.

Each of our research threads now has a clear, specific burden of proof to meet:

  • Depot Doctor: Maintenance-workflow validation and empirical testing on representative battery telemetry.
  • SHADOW: Integrated multi-fidelity feasibility and deeper aerothermodynamic domain validation.
  • ATLAS: Executed benchmark evaluations against our stated retrieval, cost, and auditability criteria.
  • ARBITER: Simulation evidence demonstrating reliable recommendation boundaries and safe no-change behavior.
  • Grid Doctor: Product-level reliability specifications and comparative testing against existing instrumentation.

Meshesha Solutions remains an early-stage R&D company. We have not yet secured an SBIR award, and the architectures described here represent active research designs and prototypes rather than government-validated products. As individual efforts mature, we intend to publish engineering notes, benchmark studies, and reproducible demonstrations—staying transparent about the distinction between a promising concept, a proposed method, and a proven result.


Meshesha Solutions LLC is an independent research and development company based in Washington State. The research directions described here are company activities and proposals, not representations of government-funded or government-endorsed technologies. References to federal programs are provided solely as context for our R&D activities.

Learn more at meshesha.solutions.

DevelopmentResearchSBIRSmall-Business

We use cookies for analytics and advertising measurement. Nothing is loaded until you choose. See our Privacy Policy.