HB-NLP-Engine — digital twin visualization
Concept visualization, not flight certified. The overlay shows values the engine declaration contains: 3.5 MN thrust, 280 bar chamber pressure, 2.8 m nozzle length, LOX and CH4, and material temperature limits of 3800 K for the chamber alloy and 3500 K for the nozzle composite. It does not show a chamber temperature. Thrust here is a theoretical ceiling from ideal-rocket theory, not a fired-engine result. That agreement is gated in verification scope.
For a number this repository does stand behind, the nozzle solver reproduces published specific impulse for Merlin 1D, Raptor, RS-25, and RL10, including sea level and vacuum where a single public source pairs them. Ideal theory stays above the published specific impulse and inside a 3% band. The original three points land within about 1%.
A .NET 9 platform for rocket engine performance analysis, with a nozzle solver validated against published flight-engine data and a CI verification gate checking selected DO-178C Level A objectives within a narrowly declared verification boundary.
Community Edition (Apache 2.0) — reference platform for integration, research, and contribution. Not certified flight software. OPEN_SOURCE_SCOPE.md is authoritative for tiers, warranties, and compliance boundaries.
git clone https://github.com/HelloblueAI/HelloblueGK.git
cd HelloblueGK
dotnet restore HelloblueGK.sln
dotnet build HelloblueGK.sln
dotnet test Tests/HelloblueGK.Tests.csproj
cd WebAPI && dotnet run
# Open http://localhost:5000/swagger| I want to… | Go to |
|---|---|
| Know what is verified vs simulated | Docs/VERIFICATION_SCOPE.md |
| Understand what's public vs commercial | OPEN_SOURCE_SCOPE.md |
| Set up locally | DEVELOPERS.md |
| Understand the codebase | ARCHITECTURE.md |
| Read the API reference | API_DOCUMENTATION.md |
| Make a first PR | CONTRIBUTING.md — docs and tests are the safe start |
| Pick a starter task | good first issues |
| Report a bug | Issue template |
| Run the interactive demo | Docs/Project/DEMO.md |
| Deploy your own instance | Docs/Deployment/DEPLOY_TO_RENDER.md |
| Reproduce CI locally | Docs/Technical/TESTING_LOCALLY.md |
This project draws a hard line between code whose behaviour is verified and code that produces well-formed output for demonstration. The line is documented in VERIFICATION_SCOPE.md and enforced in CI, because the difference is not visible from a method signature.
IdealRocketNozzle implements quasi-one-dimensional ideal rocket theory — characteristic
velocity, choked mass flow, the area–Mach relation and its numerical inverse, isentropic exit
conditions, and thrust as the momentum term plus the pressure term. Given published chamber
conditions and area ratios, it reproduces published specific impulse:
| Engine | Computed Isp | Published | Agreement |
|---|---|---|---|
| Merlin 1D, sea level | 284.2 s | 282 s | +0.8% |
| Raptor, sea level, 300 bar, area ratio 34 | 332.7 s | 330 s | +0.8% |
| RS-25, vacuum, 109% | 453.0 s | 452.3 s | +0.1% |
| RS-25, sea level, 109% | 373.8 s | 366 s | +2.1% |
| RL10A-4-2, vacuum | 456.4 s | 451 s | +1.2% |
| RL10B-2, vacuum, area ratio 285 | 474.1 s | 466.5 s | +1.6% |
The RS-25 vacuum-to-sea-level thrust ratio on the L3Harris specification sheet is 512,300 / 418,000
= 1.226. The ideal ratio at the same chamber pressure and area ratio is 1.212, 1.1% lower. Throat
area cancels, so this check does not invent a diameter. Each published number is stored with its
source in Tests/Unit/Physics/PublishedNozzleReference.cs. The build fails if the solver leaves
the 3% band or underpredicts a published specific impulse.
The tests additionally assert that ideal theory never underpredicts a published specific impulse:
every loss the ideal model neglects reduces real performance, so underprediction would indicate an
error in the algebra rather than a conservative result. IdealRocketNozzle.cs,
EngineOperatingPoint.cs, and NozzleFlowSolver.cs are at 100% line and 100% branch coverage.
The nozzle relations come from Sutton & Biblarz, Rocket Propulsion Elements, 9th ed., ch. 3 and 5,
and NASA SP-8120. Each engine number cites its own source in PublishedNozzleReference.cs.
Not claimed: this is a one-dimensional equilibrium model, not a flow solver. It says nothing about combustion stability, boundary layers, flow separation, nozzle heat transfer, or off-design transients.
Tools/CertificationGate runs in CI against a declared
boundary in certification-boundary.json.
Passing it does not mean this repository is DO-178C Level A verified.
It verifies statement and decision coverage, MC-DC with recorded independence pairs, and
requirements traceability from requirement through design and code to a passing test — then fails
the build if any objective regresses.
The boundary is deliberately narrow: a small set of files the project genuinely meets, rather than a claim over the whole repository. What a passing gate does and does not establish is recorded in the artifact itself.
coverage-floors.json sets minimum line and branch
coverage per directory, checked in CI from the measured report. The latest local run passed
1,336 tests.
The legacy AdvancedCFDSolver and AdvancedStructuralSolver read chamber pressure and still
produce schematic fields, not a flow solution or a finite-element analysis. The CFD pressure
field uses the operating point's specific-heat ratio when the model carries one. AdvancedThermalSolver
reads chamber temperature and still produces a schematic conduction estimate, not a heat-transfer
solution. Several generative and orchestration methods return constants after
Task.Delay. None of it is verified engineering, and no result it produces should be cited as an
analysis of a physical system. Each case is named in
VERIFICATION_SCOPE.md.
Published parameters for engines used as validation references and design comparisons.
| Engine | Thrust | Isp | Chamber pressure | Propellant | What the row is |
|---|---|---|---|---|---|
| Raptor | 2,200 kN | 330 s | 300 bar | Methane/LOX | Reference model. Isp is a validation point; thrust is not, because no throat area is published with it |
| Merlin 1D | 845 kN | 282 s | 97 bar | RP-1/LOX | Sea-level reference. Thrust is the published sea-level figure; the nozzle check uses Isp, not thrust |
| RS-25 | 1,860 kN sea level | 452 s vacuum | 206 bar | Hydrogen/LOX | Two operating points. Do not read this row as one condition |
| RL10A-4-2 | 22,300 lbf vacuum | 451 s vacuum | 610 psi | Hydrogen/LOX | Vacuum reference. The nozzle check uses Isp, not thrust |
| RL10B-2 | 24,750 lbf vacuum | 466.5 s vacuum | 644 psia | Hydrogen/LOX | Vacuum reference, area ratio 285. The nozzle check uses Isp, not thrust |
| HB-NLP-REV-001 | 3,500 kN | 351.5 s | 280 bar | Methane/LOX | Idealized concept. These are theoretical ceilings, not fired-engine performance |
The flight-engine specific impulses above are the validation points. HB-NLP-REV-001 has not been built or fired. Its thrust and specific impulse are the ideal-rocket ceiling at the declared chamber pressure and area ratio, and they are not a prediction of a real engine. The schematic CFD, thermal, and structural solvers are not part of this table and are not a hardware-performance claim.
| Area | What exists | Verification status |
|---|---|---|
| Nozzle performance | Ideal rocket theory solver, input-driven | Validated against the published points in PublishedNozzleReference; the build fails outside the band |
| Certification workflows | Requirements traceability, problem reporting, configuration management, test coverage, formal code review — with REST APIs and persistence | 91.5% line coverage; gates fail closed on placeholder or unverified evidence |
| Reinforcement learning | Q-learning controller for engine parameter tuning | Bellman backup, reward shaping, and action dynamics pinned by tests |
| Aerospace readiness | Mission-level classification and compliance scoring | Decision logic tested; scores derive from fixed inputs, not measurements |
| Web API | ASP.NET Core 9, JWT auth, API versioning, rate limiting, Swagger, PostgreSQL | 61.4% line coverage |
| Multi-physics solvers | Schematic CFD, structural, and thermal fields | They read an operating point and still are not a flow solution, a finite-element analysis, or a heat-transfer solution. Not a hardware-performance claim |
| Digital twin / generative design | Interfaces and orchestration | Simulation scaffolding |
Reference tooling that supports aerospace software lifecycle practices. This is not certified flight software and does not replace a qualification program.
/api/v1/certification/requirements requirements → design → code → test traceability
/api/v1/certification/problem-reports formal problem report tracking
/api/v1/certification/configuration baseline and change management
/api/v1/certification/test-coverage coverage and MC-DC tracking
/api/v1/certification/code-reviews formal review workflow
These systems fail closed. A baseline cannot be approved by the person who created it, evidence
naming a placeholder such as n/a or TBD does not satisfy a gate, and a requirement cannot be
marked verified against a test that has not passed.
Details: Certification/README.md · API Quick Start · Progress
Design targets, achieved only through your organization's own qualification program: DO-178C-oriented and NASA NPR 7150.2-oriented workflows. Export-controlled programs require separate legal review.
WebAPI (ASP.NET Core 9) auth, versioning, rate limiting, Swagger
│
├── Certification/ RTM, problem reports, config management, coverage, reviews
├── Physics/ nozzle solver (validated), CFD/structural/thermal (scaffolding)
├── Aerospace/ engine models, compliance and readiness assessment
├── AI/ reinforcement learning, generative design scaffolding
├── Core/ telemetry, health, configuration, performance services
└── Models/ shared domain types
Tools/CertificationGate DO-178C Level A gate, runs in CI
Full description, including the optional geometry-integration boundary: ARCHITECTURE.md.
Base URL: hellobluegk.onrender.com
| Endpoint | Auth | Purpose |
|---|---|---|
/Health |
none | liveness |
/Health/detailed |
bearer token | component detail |
/Health/engine |
bearer token | engine subsystem status |
/metrics |
bearer token | Prometheus exposition |
/swagger |
authenticated | interactive API browser |
Swagger requires authentication rather than being publicly readable. To configure that in your own
deployment, including optional OpenID Connect, see
SWAGGER_ACCESS.md. /Health is the only unauthenticated
endpoint.
This is a reference deployment, not an open sandbox — registration is disabled. Clone and run your own instance if you need one you control.
curl https://hellobluegk.onrender.com/Health
# Authenticated calls use a bearer token from /api/v1/Auth/login
curl https://hellobluegk.onrender.com/api/v1/engines \
-H "Authorization: Bearer YOUR_TOKEN"Full endpoint reference: API_DOCUMENTATION.md.
dotnet test Tests/HelloblueGK.Tests.csproj # all 1,214 tests
dotnet test --filter Category=Integration # integration suite
dotnet test --filter Category=Performance # performance benchmarks
dotnet test --filter 'FullyQualifiedName~IdealRocketNozzleTests' # nozzle validationIntegration and Performance are the only category traits defined, so other Category= filters
match nothing and pass while running zero tests.
Coverage and the certification gate run in the Build and Test job, which is a required check on
main — the gate and the floors can fail a merge. To reproduce the full pipeline locally, see
TESTING_LOCALLY.md.
docker build -t hellobluegk:latest -f Docker/Dockerfile .
docker run -p 8080:8080 -e Jwt__Key="a-secret-of-at-least-32-characters" hellobluegk:latest
# http://localhost:8080/swaggerSet DATABASE_URL and Jwt__Key from the environment; never commit secrets. Render is the supported
path and is described in DEPLOY_TO_RENDER.md, with database
setup in RENDER_POSTGRESQL_SETUP.md. The deployed
service builds Docker/Dockerfile.render; the plain Docker/Dockerfile above is the local
equivalent. A generic Kubernetes manifest (k8s-deployment.yaml) is included as an illustrative
example with placeholder hostnames and minimal resources; it is not exercised by CI.
Bearer-token authentication with issuer and audience validation, request rate limiting and body-size guards, input validation, security headers, and CORS restricted by configuration.
CodeQL analyses C#, Python, and the workflows themselves, and GitGuardian scans every pull request for committed secrets. A required Security Scan job fails the build on a known-vulnerable NuGet package, and a scheduled daily audit repeats that check and reports deprecated packages.
main requires passing Build and Test, Integration Tests, Code Quality Checks, and
Security Scan, plus code-owner review, linear history, and resolved conversations.
Report vulnerabilities per SECURITY.md — please do not open a public issue. Industry-standard patterns are used throughout; the Community Edition makes no FIPS or formal accreditation claim.
HelloblueGK is an independent open-source project maintained by Helloblue. It is not a fork of, affiliated with, or endorsed by LEAP 71's PicoGK geometry kernel, and it does not vendor PicoGK source.
| Question | Answer |
|---|---|
| Is this PicoGK? | No — different product and maintainer. |
Is this a fork of leap71/PicoGK? |
No — separate repository and codebase. |
| Clone folder name | Use HelloblueGK. See DEVELOPERS.md. |
| Future geometry integration | Optional; may reference PicoGK as an external library later. See ARCHITECTURE.md. |
| Tier | Available | Notes |
|---|---|---|
| Community Edition | This repository | Apache 2.0 — APIs, reference code, tests, docs |
| Hosted Platform | hellobluegk.onrender.com | Reference deployment; auth required, no open signup |
| Enterprise / Certification | Commercial | Formal compliance packages, SLAs, production support — not in this repository |
Production certification evidence and export-controlled data are not published here.
New contributors are welcome, and a first PR does not need to touch certification or security gates. CONTRIBUTING.md describes the first-hour path and how review works.
- Good first issues
- Discussions — questions before you write code
- Issues — bugs and features
- Code of Conduct
| Document | Contents |
|---|---|
| Docs/VERIFICATION_SCOPE.md | Verified engineering versus simulation scaffolding |
| Docs/Technical/TECHNICAL_LIMITATIONS_AND_ROADMAP.md | Known limitations and development roadmap |
| Docs/Technical/VALIDATION_AND_BENCHMARKS.md | Validation results and benchmark data |
| Docs/Design/AdvancedCFDSolver.md | Design description for a unit inside the certification boundary |
| Docs/README.md | Index of all documentation |
| .github/CONFIGURATION.md | CI workflows, templates, and what CI enforces on a PR |
Apache License 2.0 — see LICENSE. You may use, modify, and distribute this software, including commercially, provided you retain the copyright and license notices and state significant changes. It is provided "as is", without warranties or conditions of any kind.
Nothing in this repository constitutes a certification, airworthiness approval, or regulatory finding. Users are responsible for their own qualification programs and for compliance with ITAR, EAR, and other applicable regulations.
- SpaceX for published Raptor and Merlin engine specifications
- NASA for published RS-25 performance data and the NPR 7150.2 software engineering requirements
- RTCA for DO-178C, the basis of the objectives checked inside the declared verification boundary
- Sutton & Biblarz for Rocket Propulsion Elements, the source of the nozzle relations
- The .NET and open-source communities for the tooling this platform is built on
Helloblue, Inc. · HB-NLP Research Lab