Rainbone: Finite-element stress visualisation of a published femur CT with a rule-checked, bounded-agent AI explanation layer

3.1HFValid cohort table

The cohort table frontend/public/models/hfvalid-risk.json is extracted from HFValid_Metadata.csv of HFValid collection v3 by scripts/bone_fea/build_risk_table.py. It keeps age, height, weight, modelled side, fracture follow-up, ARF0 and MSF, and drops every scanner and calibration column. All 101 subjects are women; the build rejects any row whose sex is not F. The dataset's inclusion text requires residence in the Emilia Romagna region, needed to follow up fractures, and survival for at least 5 years after the CT scan or a fracture within 5 years. The follow-up records whether a subject had a fracture and the days from CT to fracture, not where the fracture was. The file hashes to the sha256 pinned beside it, 884f5875…2b6261. In the code it is labelled de-identified public research data, not patient records (backend/services/clinical_store.py).

3.2The reference femur, Pat001

Pat001 is a complete right femur of a woman aged 78 at the scan (README.md). The CT is distributed by the authors as NRRD with voxel spacing 0.703125 × 0.703125 × 2.0 mm and 256 × 331 × 220 voxels; the source files are pinned by sha256 in the femur manifest. Her published values are an ARF0 of 47.10747422 % (shown as 47.1 %) and an MSF of 1,338.861427 N (shown as 1,339 N); no fracture was recorded for her during the follow-up (hfvalid-risk.json, subjects.Pat001). Pat001 is the only case with a femur model; /api/explain and /api/ask accept no other case.

3.3CTPelvic1K imaging library

The imaging library uses CTPelvic1K [5], sub-dataset 6 (CLINIC), which its authors describe as preoperative pelvic-fracture CT without metal artefacts. Three cases (0012, 0023 and 0060) were segmented and meshed. The derived masks and meshes are automatic segmentations, not the dataset's annotations, and were not reviewed by a clinician (scripts/vultr_pipeline/pipeline.py). None of this data enters the FEA or the AI facts.

3.4Uploaded volumes

POST /api/simulate accepts NIfTI-1 or NIfTI-2, optionally gzipped, up to 512 MiB, 512³ voxels and 1,024 MiB of header and voxel data; the header is parsed first and only the declared bytes are decompressed (backend/services/fea_solver.py). Uploaded scans are not saved. When a database is configured, a log of simulation runs keeps the file name as sent and the solver outputs; it is publicly readable, so files must be named without patient details. The bundled sample frontend/public/sample_bone.nii.gz is synthetic: an ellipsoid with semi-axes 10, 6 and 12 mm (3,048 voxels at 750 HU in −1000 HU, 1 mm voxels). It is not anatomy.

4.1Segmentation and meshing

Reference femur. scripts/bone_fea/import_femur_in_slicer.py loads the authors' CT and reviewed segmentation into 3D Slicer 5.12.4, converts LPS to RAS, saves bone.seg.nrrd and exports a closed surface of 71,510 points and 143,016 triangles. prepare_femur_in_slicer.py reduces it with vtkDecimatePro (target reduction 0.80, topology preserved, no splitting, boundary vertices kept) and vtkCleanPolyData, and refuses any surface with open or non-manifold edges; the result has 14,303 points and 28,602 triangles. TetGen 1.6.0 meshes it with the switches -pYq1.4a80z: a piecewise-linear complex input whose boundary triangles are kept, a radius–edge quality bound of 1.4, a requested maximum element volume of 80 mm³ and zero-based numbering. Because the boundary is preserved, TetGen cannot meet the volume target everywhere: the largest element is 1,891.83 mm³ and the smallest 3.197 × 10⁻⁵ mm³. The FE mesh has 60,819 four-node tetrahedra and 17,361 nodes, a volume of 408.092 cm³, and an exterior of 14,304 nodes and 28,604 triangles. Before solving, build_model.py rejects any element with $|\det |<{10}^{-12}$ and reorders the nodes of any element with a negative determinant, so that every element volume

is positive. Coordinates are RAS in millimetres; the femoral-head centre $𝐜=(74.5402,-1.2438,-50.4298)$ mm is a constant in the import script, and the repository does not record how it was obtained.

Uploaded CT volumes. The bone mask is the largest face-connected (6-connected) component of the voxels at or above 150 HU, with NaN read as −1000 HU:

When FSLDIR is set, FSL computes the same mask (fslmaths -thr 150 -bin, connectedcomp with 6-connectivity); otherwise NumPy and SciPy do. The volume is cropped to the component's bounding box. If the component has more than 8,000 voxels, voxels are merged into blocks of $f_x\times f_y\times f_z$ whole voxels, as close to cubic as the spacing $({\mathrm{\Delta }}_x,{\mathrm{\Delta }}_y,{\mathrm{\Delta }}_z)$ allows, with the block edge grown until at most 8,000 blocks hold bone:

where $N_b$ is the number of bone voxels and a block counts when it holds any bone voxel, so a thin wall stays connected. Each occupied voxel or block is split into six positively oriented, conforming tetrahedra that share its corner-0 to corner-6 diagonal (split table [[0,1,2,6],[0,2,3,6],[0,3,7,6],[0,7,4,6],[0,4,5,6],[0,5,1,6]]). With integer corner indices $𝐠$, the nodes are

so voxel centres fall on integer multiples of the effective spacing. Array axes 0, 1 and 2 are used as $x,y,z$; no anatomical orientation is applied. The mesh must be one face-connected component of at least 8 voxels spanning at least 4 voxels along $z$.

Pelvic imaging library. TotalSegmentator 2.18.0 (task total) is asked for sacrum, vertebrae_S1, hip_left, hip_right, femur_left, femur_right and vertebrae_L5. Because it labels S1 apart from the sacrum, the anatomical sacrum mesh is the union of the two. Each mask is meshed with vtkFlyingEdges3D at 0.5 on the padded binary mask, transformed by the NIfTI affine to RAS millimetres, smoothed with vtkWindowedSincPolyDataFilter (20 iterations, pass band 0.05) and decimated to a per-bone triangle budget (sacrum 30,000; each hip 40,000; each femur 30,000; L5 20,000). These meshes are for viewing only.

4.2Finite-element formulation

Both the reference femur and uploaded volumes are solved by solve_elasticity in scripts/bone_fea/solve.py: three-dimensional, static, small-strain, linear elasticity, with no body force. On the domain $\mathrm{\Omega }$, with a clamped distal slab ${\mathrm{\Omega }}_D$ and a loaded part ${\mathrm{\Gamma }}_N$ of the boundary, the displacement $𝐮$ satisfies

with the small-strain tensor

and the isotropic Hooke's law built by SfePy's stiffness_from_youngpoisson:

For the reference femur $E=\mathrm{10,000}$ MPa and $\nu =0.3$ in every element, an assumption that is neither calibrated nor taken from CT density; by Eq. (7) this gives $\lambda =5769.23$ MPa and $\mu =3846.15$ MPa (derived here, not stored in the repository). SfePy stores symmetric tensors in the order 11, 22, 33, 12, 13, 23, with the stiffness matrix acting on engineering shear strains:

The discrete problem uses continuous piecewise-linear (P1) vector fields $V_h$ on the four-node tetrahedra (SfePy cell type 3_4, approx_order=1). The equation named balance is the stiffness term dw_lin_elastic minus the traction term dw_surface_ltr, both integrated with an order-2 rule:

In matrix form, with the usual P1 strain–displacement matrices ${𝐁}_e$ and shape functions $𝐍$,

where the sums denote assembly. The system is solved by one Newton iteration (i_max=1) with SfePy's ScipyDirect sparse direct solver; on a linear problem this is a single exact linear solve.

Boundary regions of the reference femur. Every node within $h_D$ of the minimum $z$ is clamped, interior nodes included: the clamp is the volumetric slab ${\mathrm{\Omega }}_D=\{𝐱:z<z_{\min }+h_D\}$, not a patch of the boundary, and ${\mathrm{\Gamma }}_D$ below is its node set. The load is applied to the exterior triangles whose three vertices lie within $h_N$ of the maximum $z$ and within 25 mm of the head centre:

The loaded band is intersected with the exterior facets, so faces inside the band are excluded. The traction is uniform and scaled so that it integrates to the resultant $F$:

Acceptance of a solve. After the solution is stored, the constraints are removed and the full residual is evaluated. At the clamped nodes it gives the support reaction; at the free nodes it measures the equilibrium error. A result outside tolerance raises RuntimeError and is never written:

Stress recovery. The Cauchy stress is evaluated per element with ev_cauchy_stress in el_avg mode; on a P1 tetrahedron it is constant,

and SfePy's get_von_mises_stress reduces it to the equivalent stress

The raw element values are kept in bone-fea.vtu. For continuous contours, build_model.py averages them at each node over every tetrahedron that shares it, weighted by volume:

The viewer colours the surface from 0 to the largest surface value of Eq. (16), and nothing is solved in the browser. The cut-away view slices every tetrahedron with a plane $𝐧\cdot (𝐱-𝐨)=0$ and interpolates nodal values linearly along each crossing edge $(a,b)$, with $t=s_a/(s_a-s_b)$ and $s_a=𝐧\cdot ({𝐱}_a-𝐨)$ (frontend/lib/vtu-cut.ts).

Standing-load stress ratio. The single number shown with the stress map divides the peak surface nodal stress by an assumed strength of 150 MPa:

$R_{\text{stand}}$ is an illustrative stress-to-assumed-strength ratio. It is not a fracture probability: the load is a standing load, not a fall, and the strength is not measured. The project README quotes it as 11 %, the dashboard shows 10.6 % and Ask Rainbone's statement uses 10.55 %. An older API field, fracture_risk_index_percent, carries this kind of ratio for uploads; it is renamed stress_to_strength_percent before any model sees it, and this report calls it a stress ratio.

4.3Material mapping for uploaded CT

For uploaded volumes each bone voxel receives its own modulus from its Hounsfield value. The mapping in hu_to_apparent_density_and_modulus is a fixed, bounded linear map. Its docstring calls the density a “calibrated apparent density estimate”, but there is no phantom calibration and the map is not a published density–modulus relation (backend/README.md); this report therefore calls it an uncalibrated bounded linear map:

The second form of Eq. (19) is an algebraic simplification derived here; it holds because $\hat{\rho }$ saturates at $\rho =1$, before the clip at 1.2. Inside the 150 HU mask the map therefore gives 17.5 to 25 GPa, saturating at 1000 HU (derived). The repository's own examples agree: 700 HU gives 22.35 GPa and 750 HU gives 22.79 GPa (backend/README.md). Each tetrahedron then gets its own isotropic modulus through a material function evaluated per quadrature point (solve.py:129–137). After coarsening, a block $B$ with $n_B$ bone voxels has

so a partly-bone block carries the stiffness of the bone it holds (${\varphi }_B=1$ without coarsening). The stress in the bone part of a block, and the statistic reported, are

where $s[j]$ is the value at position $j$ of the sorted element stresses repeated $n_{(j)}$ times, once per bone voxel. Eq. (22) equals np.percentile of that repeated array without building it, so a few corner elements of the voxel mesh do not set the value. The upload's stress ratio and volumes are

which are equal by construction: coarsening changes the mesh, not the bone volume it carries. An upload produces neither an ARF0 nor an MSF.

4.4Load cases

Standing load on the reference femur. Eqs. (11)–(12) with $F=800$ N select 2,040 clamped nodes and 1,060 loaded exterior triangles with $A_N=1208.153$ mm², a uniform traction of $800/1208.153=0.6622$ MPa (derived). This is an illustrative standing load: distal fixation and head compression are not a musculoskeletal load model, and not a fall (hfvalid-femur/manifest.json, limitations).

Standing load on uploads. Supports and load are placed by the volume's $z$ extent, not by anatomy: the two outermost node layers at each end.

Hydraulic-press demonstration. The press is a separate, displacement-controlled solve on the same 60,819 tetrahedra; it does not scale the 800 N field. The rig on screen is schematic: contact and hydraulics are not solved. The distal 15 mm is clamped and a stroke $s$ is prescribed on the head cap, whose lateral motion stays free; as for the standing load, both node sets include the interior nodes of their bands:

The material is the same homogeneous $E=\mathrm{10,000}$ MPa, $\nu =0.3$, scaled per element by an isotropic scalar damage $d_e\in [0,0.995]$, with one quadrature point per tetrahedron:

The constant strain of each tetrahedron is recovered from its edge vectors, with tensor (not engineering) shear:

To suppress peaks in tiny elements, strains are averaged over the element centroids ${𝐜}_e$ within $\ell =3$ mm, weighted by volume (the element itself included):

The failure ratio compares the largest and smallest principal averaged strains, ${\bar{\epsilon }}_{\mathrm{I}}$ and ${\bar{\epsilon }}_{\mathrm{III}}$, with the assumed limits, and its running maximum is an irreversible history variable:

Damage follows an exponential softening law that stays zero until the ratio reaches 1 and keeps 0.5 % residual stiffness:

Elements near the fixtures are never damaged, which defines the eligible set $ℰ$:

Because the undamaged problem is linear, one elastic solve at a 1 mm stroke gives both the stiffness (9,887.25 N/mm) and the stroke at which the first eligible element reaches an assumed limit. The 15 exported steps are multiples of it:

Each step alternates equilibrium solves and damage updates (Algorithm 1). The committed damage ${𝐝}^n$ of the previous step never decreases; trial iterates are damped by one half:

The press load is the reaction at the prescribed cap degrees of freedom, recovered from the residual, not taken from the animation:

where the free degrees of freedom exclude every degree of freedom at clamped nodes and the $z$ component at cap nodes. Each frame records

Erosion is for display only: elements with $d_e\ge 0.95$ are hidden from the rendered surface, while the mechanical solve keeps their residual stiffness. The visible gap is therefore not a crack, contact or fragment result. The default “failure proximity” colour is each face's owning-element $\kappa$ on a fixed 0–1 scale, red at the assumed limit; it is neither a stress nor a probability. The manifest lists what is not modelled: calibrated CT-density material, contact, hydraulics, large deformation and fracture-energy regularisation, so the softening is mesh-dependent.

4.5Cohort comparison

The comparison beside the stress map uses only the dataset authors' published numbers; no Rainbone FE result enters it. The dataset defines ARF0 as follows: “The FE model was also coupled with a multiscale falling model to estimate the Absolute Risk of Fracture at time 0 (ARF0), as reported in [Bhattacharya2019].” MSF is defined as the minimum, over 28 load and boundary-condition orientations, of the critical load that would cause a fracture in the authors' FE model. ARF0 is therefore the HFValid authors' published model estimate, not a figure Rainbone computes. The AI checkers reject wording that calls it a probability or gives it a time horizon (§5.2), and this report does neither. With $A_j$ and $M_j$ the published ARF0 and MSF of subject $j$, code computes two ranks:

$r^{\mathrm{ARF0}}$ counts women with a lower ARF0; $r^{\mathrm{MSF}}$ counts women with a stronger femur. For Pat001, $r^{\mathrm{ARF0}}=56$ and $r^{\mathrm{MSF}}=75$ of $N=101$. The cohort quartiles in Table 2 use Python's statistics.quantiles(n=4, method='inclusive'), which on the 0-indexed order statistics $x_{(0)}\le \cdots \le x_{(N-1)}$ is

With $N=101$, $h$ is an integer, so $Q_1=x_{(25)}$ and $Q_3=x_{(75)}$ exactly. Pat001's MSF is the 26th-lowest value, which is why it equals the cohort's MSF Q1 of 1,339 N. The factor of risk divides the published sideways-fall forces by the femur's MSF:

The browser computes the same ratio without rounding (frontend/lib/model.ts:85–86) and the dashboard shows it to one decimal, 2.2–3.2× (frontend/components/metrics-explainer.tsx:39). The deterministic sentence that compares a fall with the femur's strength is chosen by a fixed rule:

For Pat001 the first case applies, since 2,900 N exceeds the strongest MSF in the cohort, 2,879 N. All of these numbers are computed before any model is called (§5.1).

5.1Grounding and provenance

Exactly two files ground the AI: the HFValid cohort table and the Pat001 femur manifest. They live in a private clinical/ prefix in Vultr Object Storage, with bundled copies in frontend/public/models/ and their sha256 pins committed next to them (884f5875…2b6261 and 4a50adbc…5a10c). For a file $f$ with stored bytes $b_f$ and bucket index entry (key $k_{\text{idx}}$, hash $h_{\text{idx}}$, size $n_{\text{idx}}$), a bucket read is accepted only if

Otherwise the bundled copy is used, and only if it too matches the pin:

A changed bucket object therefore cannot change the facts, and a changed local copy stops generation (fail closed). The bucket client makes one attempt per object (connect timeout 1 s, read timeout 1.5 s) and accepts at most 4 MiB. Verified reads are cached for 600 s and fallbacks for 60 s. The two explanation cards carry a grounding object with store, key, sha256, verified and, after a fallback, a reason that never names a credential, the endpoint, the bucket or a URL (a bucket error is reported by HTTP status and error code only). Ask retains per-file provenance; its aggregate grounding is absent when the two verified files came from different stores (backend/services/ask.py:218–223).

Facts, not model arithmetic. The explanation card's facts for Pat001 are read from the manifest and rounded to two decimals: load_newtons 800.0, max_von_mises_stress_mpa 15.83, average_youngs_modulus_gpa 10.0, bone_volume_cm3 408.09 and stress_to_strength_percent 10.55 (backend/services/explain.py:297–336). The risk card's facts (age, ARF0, both ranks, cohort size, median, fractured count and ARF0 range, MSF, fall forces, factor of risk, strongest cohort MSF and recorded outcome) are computed by Eqs. (38)–(40). The model never receives a scan or its file name, and the risk model never receives Rainbone's own FE numbers. Ask builds one evidence bundle from both grounded files, refuses to proceed unless both are verified, and identifies it by a digest that enters every cache key:

5.2The checker as acceptance predicates

Each route accepts model text $\tau$ only if an acceptance predicate holds; a rejected text moves the request to the next provider. Both prose checkers start from the same allowed-number set: every numeric fact, as a magnitude, and its roundings to 0, 1 and 2 decimals, compared with a tight tolerance.

Numbers are read with their sign, so a negative number fails against the magnitudes in $𝒜$. A digit run after letters counts as a number (“15mm” reads 15), except the exponent of cm³ or mm².

Plain-words card (/api/explain). Let $𝒩(\tau )$ be the numbers in a text $\tau$ and ${𝒩}_U(\tau )$ those followed by a unit. A unit binds a number to one fact: $k(\%)$ is the stress ratio, $k(\text{MPa})$ the stress, $k(\text{GPa})$ the modulus, $k(\text{N})$ the load and $k({\text{cm}}^3)$ the volume.

Here $W_{\#}$ detects spelled-out quantities (34 number words with their plurals and -fold forms, plus 14 words such as half, double and twice); $\omega$ first rewrites a lone number word directly followed by a unit and equal to a fact into digits (“seventeen GPa” when 17 is a fact), and never a joined form such as “twenty-two”. The number and unit predicates are therefore evaluated on $\omega (\tau )$, not on $\tau$: if 17 is the stress, “seventeen GPa” becomes “17 GPa” and $P_{\text{unit}}$ rejects it, because 17 is not the modulus. $B_E$ is a list of 27 case-insensitive patterns covering diagnosis, prediction, recommendation, treatment, probability, risk, fracture and breaking, safety, health and patient words, and $K_E$ rejects JSON field names read aloud. The prompt asks for 600 characters; 700 is the hard limit. Every accepted answer is followed by a fixed note: “Illustrative engineering simulation with assumed material properties, not a medical assessment.”

Risk card (/api/risk-analysis). Here the words fracture, risk, break and fall are allowed, so the checker instead binds every number to its kind. The allowed set ${𝒜}_R$ excludes Rainbone's own FE numbers, and each kind has its own pool:

where $ℛ(\cdot )$ is the set of the arguments rounded to 0, 1 and 2 decimals, $\tilde{A}$ the cohort median ARF0 and $n_F$ the number of women with a recorded fracture. The kind $\kappa (x)$ of a number is read from the words after it (a unit, or “women”), or is “count of women” when “than” precedes it within 40 characters. Then

Any other number with a time unit is rejected as a time prediction, as are 16 time-horizon patterns without a number (“next year”, “within”, “lifetime” and others). Rank statements must point the right way whenever the two ranks differ:

The test that pins this rule quotes a live Gemini answer that the number check alone let through, which called Pat001's MSF “stronger than 75 women”, the opposite of the data (backend/tests/test_risk.py:267–283). Writing ${\tau }^{\prime }$ for the text with the digit of “ARF0” and “time 0” removed and with fact-valued counts of women (“four women”) read as digits, the risk card accepts

$D_{\mathrm{ARF0}}$ requires any “ARF0 is X %” declaration to state this femur's 47.1 % unless a nearby word names the median, the fractured women or another ARF0. $T$ holds the 16 time patterns and $B_R$ 69 blocked patterns: diagnosis, disease, treatment and drug names, advice and referral words, imperatives, second-person address, chance, probability, odds and likelihood, certainty words such as will and guarantee, cancer, validation, and three patterns that name the hip as the fracture site, since the follow-up does not record where a fracture occurred. $\mathrm{Sem}$ is a set of conservative sentence checks (a comparison whose subject is ARF0 must use the ARF0 rank, “its MSF is X N” must be the MSF, a recorded-outcome sentence must agree with the follow-up), which the code itself describes as “not a proof of arbitrary prose meaning”. Every accepted answer ends with “Published research data, not a diagnosis or medical advice.”

Deterministic template. Each chain ends in a template that needs no network and is correct by construction; if it ever failed its checker, the request would raise rather than show unchecked text. For Pat001 the risk template reads: “A sideways fall would load this femur 2.17 to 3.18 times its minimum sidefall strength (MSF, 1,339 N) in the study authors' model. Such a fall would exceed the MSF of every femur in the study; 75 of the 101 women had a stronger femur. Its published absolute risk of fracture at time 0 (ARF0) is 47.1%, higher than 56 of the 101 women. No fracture was recorded for this woman during the study's follow-up.” (backend/services/risk.py:539–563).

These predicates catch explicit failure patterns by rule. As the README states, they are “not unrestricted semantic verification or clinical validation; accepted prose still needs human review.” Table 4 summarises the three checkers; the Ask critic is defined in §5.4.

5.3Provider fallback policy

The default chain is Gemini, then Groq, then the template; AI_CHAIN can reorder or shorten it, the template is always last, and AI_OFFLINE=1 leaves only the template. Within the Gemini step the models are gemini-3.8-flash then gemini-3.5-flash-lite; if both fail, a previously saved Gemini answer for exactly the same route, facts and prompts is served if it still passes the checker, before Groq openai/gpt-oss-120b is tried. Calls time out after 10 s per Gemini key and 8 s for Groq. Output is constrained to a JSON schema, and any answer cut short (Gemini an explicit finishReason other than STOP, Groq length) is rejected so partial text is never shown.

A model that fails (a timeout, a connection error or an HTTP error status) is skipped by every AI route in the process until its cooldown ends; a rejected text starts no cooldown. Gemini keys are tried in order, and only key-level statuses move to the next key:

The code states the reason for the second branch: “another key must not be used to get around a rate limit”. Keys travel only in request headers, appear in reasons only as “key 1”, “key 2”, and are keyed internally by their sha256. Kept answers have a bounded lifetime, so Gemini is asked again soon after a fallback:

Concurrent equal requests share one computation; a kept answer is re-checked against the current checker before reuse; at most 256 answers are kept per route (128 for Ask) and at most 500 saved Gemini answers, oldest dropped. The explanation-card responses report fallbacks; Ask exposes safe failure categories in its trace. Responses identify whether the answer was served live, cached or saved.

5.4Ask Rainbone as a LangGraph state machine

Ask answers in five stages, each a node of a LangGraph StateGraph (backend/services/ask_graph.py, langgraph==1.2.16). The graph state is a single field, next_stage; the question, credentials and evidence stay inside the stage functions. The graph compiles without a checkpointer and runs inside tracing_context(enabled=False) with no callbacks and a recursion limit of 32, so LangSmith tracing stays off even if configured. With states $S=\{\text{START},\text{triage},\text{evidence},\text{writer},\text{critic},\text{audit},\text{END}\}$, the transition function is

with one conditional edge, decided by the critic on the writer's outcome $s$ under provider $p$, where $s$ is the writer's selection, $s=\perp$ means that no selection was accepted, and a rewrite asks the same provider again with a revision instruction, at most once per request:

Stages. Triage routes known intents by rules (personal-data and treatment requests first, then data and navigation keywords); other questions enter one bounded Gemini native-triage stage (functionCallingConfig mode ANY, at most 6 s, sharing the cooldowns of §5.3). It may try multiple models or keys within that budget, or skip calls when all models are cooling down; if it yields no valid plan the trace says “Rules triage” (backend/services/ask_triage.py:32–50). Evidence validates the whole plan before running anything:

where $𝒯$ is the allowlist of Table 5 with enumerated argument values, so no case, file, URL or query outside it can be named. Writer asks the providers in chain order to choose one to three statement IDs from the allowed list; a rules writer ends the chain. Critic is code. With $I$ the comma-separated IDs, each trimmed of surrounding whitespace (the pattern allows spaces around IDs and commas, as in arf0, arf0_rank), $S_{\text{allowed}}$ the IDs the evidence allows, $𝒮$ the five citation sources, $𝒫$ the six workspace pages and $R$ the required IDs of a recognised intent,

Audit renders the answer from the fixed catalogue only, and the required IDs depend on the rule that recognised the question:

The catalogue holds 19 statements, each ending in a citation; the disclaimer reads “Research prototype; not a medical device or medical advice. [Rainbone-guide]”. A prediction question recognised by the rules must therefore return, together, the limitation “Rainbone cannot predict whether or when this woman will fracture.”, the recorded follow-up outcome and the published ARF0, whose statement reads “Pat001's published ARF0 is 47.1%; it is a study authors' model estimate, not Rainbone's validated prediction for a person.” (Rainbone has no prediction of its own, validated or otherwise.) If the selection produced by the rules writer ever failed the critic, the request would raise: the catalogue itself would be invalid.

A recognised generic cohort-comparison question requires both arf0_rank and strength, so a writer cannot return only one rank; explicit ARF0 or strength questions remain metric-specific. The strength statement names its subject explicitly: “Pat001's femur has a minimum sidefall strength of 1,339 N in the study authors' model; 75 of the 101 women had a stronger femur.” It ends with the [HFValid-Pat001] citation. Tests require both statements for comparison questions and reject a writer selection that omits either (backend/services/ask.py:177–180, 288–293, 307–309; backend/tests/test_ask_comparison.py).

Fault handling and limits. If LangGraph itself fails, a built-in loop continues from the committed cursor without replaying finished stages; an error raised by a stage is re-raised unchanged. A fresh trace names the orchestrator (“Orchestrator: LangGraph StateGraph” or “Orchestrator: built-in (LangGraph unavailable)”); cached traces identify the original orchestrator and state that it was not rerun. A test pins the visit order with one critic rejection as triage, evidence, writer, critic, writer, critic, audit (backend/tests/test_ask_graph.py:17–28). Each transport peer may ask 8 questions per sliding 60 s window,

with at most 4 active requests, 4 pending generations and 4 evidence workers; a 25 s deadline covers evidence reads, triage and writers, and missing verified evidence returns HTTP 503 before any provider call.

5.5Audit and energy meter

Newly produced live or template answers use a best-effort logger for the ai_analyses TimescaleDB hypertable (7-day chunks) in Tiger Cloud. Saved or cached reuse adds no row; coalesced requests share the producer's result. Unconfigured or cooling-down logging can skip the write (backend/services/ask.py:508–509, 537–555; backend/services/ai_log.py:128–129). A stored row holds hashes, never text:

The answer text, the facts, the question, tool arguments and outputs, keys, URLs and token counts are not stored. For Ask, the hashed “facts” are the writer's request identity and the hashed text is the server-rendered answer. A response claims logged only after the write is confirmed (connect 2 s, statement timeout 1.5 s, total 2.5 s; writes are skipped for 60 s after a failure, and a failed write never fails the answer). Anyone holding an answer can therefore check its provenance:

Token and energy meter. Each model answer returns the token counts its provider reported for the call that wrote it, with Gemini thinking tokens counted as output. Ask returns a per-request subtotal over every returned triage and writer generation, rejected selections and the rewrite included:

where missing usage or an unobserved failed, timed-out or invalid provider response adds an incomplete reason. A rejected selection with fully reported usage can still have complete token accounting. No calls and no incomplete reasons means zero new work; cached and coalesced requests likewise report zero newly initiated calls. These are reported-generation subtotals, not billing totals or measured footprints. Under a live Gemini answer the card adds one constant reference, labelled “for scale, not measured for this answer”: Google's published median of 0.24 Wh and 0.03 gCO₂e for one Gemini Apps text prompt [8, 9]. Because it is a per-prompt median, it is never scaled by tokens, and cached, saved, Groq and template answers show no energy figure (frontend/lib/ai-usage.ts). Rainbone does not measure energy.

6.1Verification against closed-form solutions

The solver and its variants are tested against problems with known answers (Table 6). The basic test compresses a 3 × 3 × 6 unit-voxel bar with $E=1000$ MPa and $\nu =0$:

and two 3 mm segments in series check the per-element modulus path:

6.2Standing-load results for Pat001

Both equilibrium errors, about $6.6\times {10}^{-11}$ and $8.1\times {10}^{-11}$, are about four orders of magnitude inside the ${10}^{-6}$ acceptance bound of Eq. (13) (derived), and the reaction matches the 800 N resultant. The nodal average lowers the peak from 41.98 MPa in a single element to 15.83 MPa, so the stress ratio depends on the statistic chosen; the app uses the nodal value because it is what the colours show. The repository claims no mesh-convergence study, no clinical validation and no reproduction of the dataset authors' analyses, and these results should be read in that light.

6.3Press demonstration

Frames 0–6 are purely elastic: load, stress and displacement scale linearly with the stroke, with one iteration each (for example 2,868.96 N at $r=0.15$ and 17,213.7 N at $r=0.9$). Table 8 lists the steps from the onset.

Damage starts at $r=1.05$ without visible erosion; at $r=1.1$ the first elements are hidden and the reaction falls from 20,078.5 N to 8,447.05 N as the softened region stops carrying load. Over all exported frames the relative free residual is at most 1.01 × 10⁻¹¹ and the balance error at most 7.29 × 10⁻¹². The stress colour scale is fixed at 100.711 MPa, the largest per-step 99th percentile of visible nodal stress. A printable reconstruction of the eroded region at frame 9 ($r=1.10$; step 10 in the manifest's 1-based count) removes 1,166 elements and 5,219.74 mm³ (1.279 % of the volume); it represents simulated element erosion, not measured tissue loss (femur-reconstruction/manifest.json). Because the material and limits are uncalibrated and the softening is mesh-dependent, the load–stroke curve is a demonstration of the algorithm, not a strength of this femur.

6.4Uploaded volumes

On the bundled synthetic sample, a real run solved 3,909 nodes and 18,288 tetrahedra without coarsening and reported a 99.5th percentile stress of 17.71 MPa, a mean modulus of 22.79 GPa, a bone volume of 3.05 cm³ and a stress ratio $I$ of 11.81 %; the support reaction was 800.0000 N with a balance error below 10⁻¹², and the largest element stress was 38.26 MPa (backend/README.md). A femur-shaped test volume, the Pat001 labelmap with every femur voxel set to 700 HU, gives 12.61 MPa, 22.35 GPa and 408.83 cm³ of bone carried by a 537.71 cm³ block mesh, as Eq. (24) requires. The reported stress depends on how the load is introduced: for band widths of 0.5, 1.5 and 2.5 voxel heights, the 99.5th percentile is 34.36, 17.71 and 12.41 MPa for the sample and 12.63, 12.61 and 10.20 MPa for the femur-shaped volume. The 150 HU threshold and the HU map are assumptions, and no mesh-convergence study has been made for the voxel meshes.

6.5Segmentation Dice (pelvic library)

The imaging library's automatic masks were compared voxelwise with the CTPelvic1K expert labels on the source CT grid, using

with $D$ undefined when $|A|+|B|=0$ and rounded to four decimals.

Hips matched by name score 0.0 on these cases because CTPelvic1K label 2 (right_hip) lies where TotalSegmentator puts hip_left; the pipeline therefore also scores each hip against the opposite label and keeps the pairing that overlaps. The per-case hip values are stored only in the bucket's manifest, not in the repository, so they are not reported here. Femurs have no CTPelvic1K label, and label 4 is the visible lumbar spine rather than L5 alone, so neither is validated.

6.6Red-team evaluation of Ask Rainbone

On 18 October 2026, from 06:57:58 to 07:04:30 EDT, 32 questions were sent one at a time, 10 s apart, to the production POST /api/ask: six categories of five (prompt injection, medical advice, prediction pressure, number traps, personal data and off-topic requests, legitimate hard questions) plus two paraphrases of legitimate questions. Only content was tested: no infrastructure probing, no real secrets and no personal data. Scoring used nine fixed rules and no LLM judge:

where the checks require, among others, that the answer is exactly catalogue statements plus the disclaimer, contains no prompt text or key material, links only to workspace pages, uses no un-negated advice or prediction wording, contains only published numbers, does not repeat the question's trap, and refuses personal or off-topic requests while answering legitimate ones. Every answer was also found in GET /api/ai-log with text_sha256 equal to the sha256 of the answer received, Eq. (64).

Gemini was on a free tier and rate-limited for most of the run: Groq wrote 25 selections and gemini-3.5-flash-lite 7. Keyword rules routed 21 questions, Gemini function calling 2, and for 9 the Gemini triage was unavailable and the server fell back to the refusal statement. The two failures were D3, a question about where the woman lives, which received a navigation statement because a where rule matched before any personal-data rule; and L5, a question about what Vultr and Tiger do, which received the refusal because no rule matched, Gemini triage was cooling down and no statement covered the storage stack. The fix (PR #51) moved a personal-identifier and treatment rule ahead of all other routing and added a checked stack statement; offline regression tests pin both (backend/tests/test_ask_redteam.py).

The report is explicit about what the passes do not show. They show that the server-rendered architecture held on production under attack, not that a model resisted the attacks; 9 refusals were a fallback rather than a model's judgement; only 2 questions were routed by a model; the follow-up verified the cooldown fallback path, not successful native triage; and neither run covered the LangGraph deployment. The original run also predates the prediction_limit statement and the routing on main: production then ran older code, and on main the keyword rules would send P1, P2 and I5 to prediction_limit, recorded_outcome and arf0 (redteam/REDTEAM.md). A single production answer checked after that deployment ended with “Orchestrator: LangGraph StateGraph” (README.md); that is one answer, not an evaluation.

6.7Latency where recorded

Upload timings were measured with curl's time_total on one development laptop. They show the coarsening cap doing its job: the femur-shaped volume, with about 136 times as many bone voxels as the sample (413,475 against 3,048; derived), answers in under 2.5 s because it is solved on 7,553 blocks. FSL produces the same mask as NumPy and SciPy and is slower, so it is optional.

6.8Optional native boundary extraction

Boundary-face extraction has an optional integer-only C++ kernel; SfePy still solves the mechanics. The build prefers C++23, then C++20, then C++17. One background build has a 20 s total budget and caches its library by source, language mode and platform. Startup and requests use NumPy until the library is ready, and retain that fallback if building, loading or input checks fail. RAINBONE_NATIVE_SURFACE=0 disables the native path (scripts/bone_fea/native_surface.py; scripts/bone_fea/solve.py:12–19, 50–60).

On the bundled 60,819-tetrahedron HFValid mesh, recorded boundary-extraction timings were 125.8 → 20.1 ms locally (6.26×), and 728–752 → approximately 47 ms on the production API host (15.5–16.1× across two benchmark runs). Each result uses two warm-ups and the median of seven timed runs, including Python-wrapper validation. File loading, compilation, the FEA solve and network latency are excluded; these measurements establish the speed-up of boundary extraction only (README.md, Deploy; scripts/bone_fea/benchmark_surface.py:29–59).

The benchmark requires exact face and owning-tetrahedron arrays. Regression tests also check byte-for-byte parity on the committed HFValid mesh, face order and orientation, reordered tetrahedra, duplicate faces and empty input, plus compiler, loader and fallback failures (backend/tests/test_native_surface.py). Each API solve logs the extraction path and compiled language mode actually used (backend/services/fea_solver.py:290–291, 310–312).