Henqo is an AI-native systems-engineering platform that takes a set of requirements for a physical product and produces a release-ready design package with traceable evidence. The platform combines a language-model orchestrator, domain-specific quantitative surrogates, physics-based simulation backends, and a rule-governed release engine into a single, auditable workflow.
One-sentence version. Henqo turns requirements into manufacturable designs with traceable evidence — faster than a human team, and with comparable or better rigor for the decision classes where surrogate reliability has been demonstrated.
What the platform is not. See §3 (Non-Goals).
Systems engineering today is bottlenecked at the integration layer. Individual tools — CAD, FEA, CFD, optimization solvers — are mature. The workflow that connects them — requirements decomposition, design-space exploration, multi-disciplinary analysis, evidence collection, manufacturing review, release authorization — is still largely manual, document-driven, and expert-dependent. This makes early-stage design exploration slow and expensive, late-stage evidence assembly fragile, and design iteration across disciplines a coordination problem rather than a technical one.
Henqo addresses the integration layer directly. It does not replace CAD, FEA, or CFD. It provides the connective tissue — the IR, the routing, the evidence chain, the policy enforcement — that makes those tools composable in a governed workflow.
The following are explicit non-goals for Henqo v0–v2. Pursuing any of these without a formal scope extension is prohibited.
| Non-goal | Reason |
|---|---|
| General-purpose LLM assistant | Henqo is a domain-specific engineering system; general chat dilutes both product focus and trust boundaries |
| Document generation or report writing | Henqo generates IR artifacts and DecisionPackages; formatted reports are a thin output layer, not the product |
| CAD authoring or geometry editing | Henqo consumes and references geometry; it does not replace Solidworks, NX, or FreeCAD |
| Autonomous release authorization | No Henqo agent may sign a ReleaseManifest; that action requires a human signatory in every release class |
| Universal domain coverage at v0 | v0 targets one exemplar domain (EDF propulsion pod); domain expansion is a v1/v2 milestone |
| Cloud-only operation | The stack must run on a single 32 GB GPU workstation for inference and surrogate training; cloud is opt-in burst, not required |
| Real-time control or embedded deployment | Henqo operates in design-time and manufacturing-planning mode; it does not produce embedded controller code |
Primary users (v0–v1). Systems engineers and design engineers at small-to-mid-size deep-tech hardware companies (aerospace, robotics, EV powertrain, industrial robotics, defense subsystems). These users have domain expertise but are not ML practitioners. They interact with Henqo through a CLI and a structured API; they do not write surrogate training code.
Secondary users (v1–v2). Manufacturing engineers who need to review DFM outputs and sign release packages. Lead systems engineers who approve design gate decisions. Program managers who need milestone evidence dashboards.
Explicit non-users (v0). Regulators, end customers, and procurement staff. Henqo is an internal engineering tool; any interface with external stakeholders is out of scope for v0.
All v0 development is validated against a single concrete exemplar: an electric ducted fan (EDF) propulsion pod for a small UAV platform (≤ 5 kg MTOW).
Top-level requirements for the exemplar.
| ID | Requirement | Value | Criticality |
|---|---|---|---|
| REQ-001 | Static sea-level thrust | ≥ 50 N | Critical |
| REQ-002 | System mass (pod + motor + ESC) | ≤ 800 g | Key |
| REQ-003 | Aerodynamic efficiency (thrust/shaft power) | ≥ 0.70 | Key |
| REQ-004 | Max continuous electrical input power | ≤ 1,800 W at 44.4 V nominal | Critical |
| REQ-005 | Fan-tip-to-duct clearance | 0.3–0.8 mm radial | Critical |
| REQ-006 | Duct internal diameter | 120 ± 1 mm | Key |
| REQ-007 | Operational inlet temperature range | −20 °C to +55 °C | Significant |
| REQ-008 | Structural safety factor on blade root | ≥ 1.5 at max RPM + worst-case gust | Critical |
| REQ-009 | Manufacturability by a 3-axis CNC + metal PBF shop | Must pass MRL 5 at PDR | Key |
| REQ-010 | Full design package traceability | All evidence linked to requirements | Critical |
Why this exemplar. The EDF pod requires CFD (duct aerodynamics), structural FEM (blade and housing), thermal analysis (motor and ESC cooling), tolerance stack analysis (blade tip clearance), DFM review (duct and blade manufacturing), and a complete evidence chain. It is complex enough to exercise every Henqo subsystem without being so large that it obscures the architecture.
Done when:
| Criterion | Acceptance condition |
|---|---|
| IR persistence | ComponentRevision, AssemblyRevision, Requirement, Characteristic, Prediction, SimulationCase, ProvenanceBundle can be created, read, and linked via the graph service CLI |
| Manual requirement ingestion | The 10 EDF requirements can be ingested as Requirement IR entities with Characteristic allocations |
| Surrogate S1 (CFD) operational | AirfRANS-trained neural operator produces predictions with TrustBundles; applicability score computed |
| Single DFM pass | CNC rules DFM-CNC-001 through DFM-CNC-007 evaluated on a sample duct geometry; violations produced as DFMViolation sub-objects |
| CLI tool invocations | run_cfd_case, compute_manufacturability_report, attach_evidence all callable from CLI with correct IR side effects |
| One passing benchmark | S1 benchmark passing per benchmark-eval-plan.md §3 |
| End-to-end trace | Requirement → Characteristic → Prediction → ProvenanceBundle chain exists in the IR for at least two EDF requirements |
v0 is not done if: any tool invocation lacks provenance; any Prediction is written to a Characteristic without a TrustBundle; the IR graph cannot be exported and re-imported without loss.
Done when:
| Criterion | Acceptance condition |
|---|---|
| All five surrogate families operational | S1–S4 surrogates benchmarked; S5 integration benchmark passing |
| Automated design-space exploration | generate_candidate_design tool produces ≥ 10 EDF design variants with Prediction-backed Characteristics |
| Automated DFM for all major process types | CNC, additive PBF, and assembly DFA rules fully evaluated; MRS computed |
| DecisionPackage generation | generate_decision_package produces a complete IR-linked DecisionPackage for any design candidate at Exploratory decision class |
| Design Gate evidence path | At least one EDF Characteristic demonstrates the full unverified → surrogate_estimated → simulation_validated state transition |
| Web API | All tool contracts callable via HTTP/JSON; OpenAPI spec published |
| Surrogate trust policy enforced | Policy engine rejects any Prediction that fails TrustBundle completeness gate |
| Benchmark regression suite | All S1–S5 benchmarks run as CI checks; regression blocks deployment |
Done when:
| Criterion | Acceptance condition |
|---|---|
| Full EDF release package | ReleaseManifest generated for the EDF exemplar at MRL 7, signed by simulated SE+ME+QA roles |
| Evidence completeness enforcement | All 10 evidence completeness rules (per manufacturability-subsystem-spec.md §10) enforced by release gate service |
| Human approval workflow | Escalation events routed to the correct role (LSE, CE, Independent Reviewer); approvals stored as ProvenanceBundle entries |
| Optimization loop | Multi-objective optimization over EDF design variables (thrust, mass, efficiency) producing Pareto-front candidates |
| Multi-program support | Two programs (EDF + one additional domain) share the same IR graph service without data leakage |
| Stale evidence detection | System detects and flags stale Predictions, SimulationCase results, and ProcessCapability entries automatically |
| Audit log completeness | Every state transition, tool invocation, and approval is reconstructible from ProvenanceBundle chain alone |
These constraints are permanent — they are not negotiable per-milestone and cannot be overridden by an agent without a human-signed design decision record.
| Constraint | Rule |
|---|---|
| No autonomous release | No agent may set manifest_status = active on a ReleaseManifest. At least one human signatory is required regardless of automation level |
| No untrustworthy predictions | No Prediction may be written to a Characteristic without a complete TrustBundle. Violation is a hard IR-layer rejection, not a warning |
| No silent fallback | When surrogate abstains, the abstention event must be surfaced to the engineer with the specific triggering condition. Silent use of a Prediction that failed its class threshold is forbidden |
| Simulation result precedence | Where both a Prediction and a SimulationCase result exist for a Characteristic, the SimulationCase result is the authoritative value. Agents may not suppress or hide simulation results that contradict surrogate predictions |
| Class A DFM violations block | No design may advance to manufacturing review with an open, unwaived Class A DFM violation |
| Constraint | Rule |
|---|---|
| IR is the single source of truth | No service may maintain a private database of engineering state that is not reflected in the IR graph. Cross-service state synchronization happens through the IR, not through private APIs |
| No schema forks | All services must consume the canonical schema package (per canonical-schema-spec.md). Forking schema in a service is forbidden |
| No direct simulator coupling | Services must call simulators through the simulation job service adapter, not directly. This ensures consistent provenance recording |
| Adapter boundary | External tools (CAD systems, meshing tools, CFD solvers, FEM solvers) must be wrapped behind adapters. Business logic must not import solver-specific data formats directly |
| Constraint | Rule |
|---|---|
| Single-node inference | All surrogate inference must be feasible on a single 32 GB GPU (VRAM budget per deep-research-report (4).md compute envelope table). Models that exceed this budget cannot be merged to main without an explicit hardware upgrade decision record |
| Quantized orchestrator | The LLM orchestrator must operate in 4-bit quantized mode during inference. Unquantized inference is allowed in training pipelines only |
| Sequential surrogate training | Surrogate models are trained one at a time on the local GPU. Parallel training requires a cloud burst configuration that must be explicitly enabled |
| Constraint | Rule |
|---|---|
| Provenance required | No external dataset may be ingested into the IR without a ProvenanceBundle recording the dataset name, version, license, and ingestion agent |
| Unit validation at ingestion | All numerical values entering the IR must carry a unit field and pass canonical-SI conversion. Values without units are rejected at the schema validation layer |
| No personal data | The IR must not store personally identifiable information. Engineers are identified by role IDs (not names or email addresses) in ProvenanceBundle approval records |
| License compliance | Datasets with license restrictions must be tagged with the restriction in their ProvenanceBundle. Agents must not use license-restricted data in outputs that may be published externally without a human license review |
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Surrogate prediction quality insufficient for Design Gate decisions | Medium | High | Mandate benchmark-eval-plan thresholds before Design Gate use; maintain simulation fallback |
| Schema complexity slows initial development | High | Medium | Start with minimal viable subset (MVP schema per canonical-schema-spec.md §2); extend incrementally |
| LLM tool routing mistakes on novel domains | Medium | Medium | S5 integration benchmark catches routing errors; wrong-surrogate routing rate ≤ 5% required |
| Human approval bottleneck in v2 workflow | Medium | Low | Design escalation workflow (surrogate-trust-policy.md §8) so that surrogate-only decisions at Exploratory require no human approval; only gate-crossing decisions require sign-off |
| IR graph performance at scale | Low (v0–v1) | Medium | Graph service benchmarked at 10k–100k entities; beyond that requires horizontal scaling plan |