FISICA: A Deployed Service for Plantar-Pressure and Posture Assessment with Ontology-Grounded Recommendation

Juhwan Song; Heejung Kim; Juntae Noh; Jonghak Ryu; Huiju Park; Junseong Lee; Dohyeon Ahn; Byungwoo Jo

Figure 1: Exploded view of the FISICA Scale. The device integrates the cover, silicone and conductive layers, a pressure-sensor PCB, tempered glass, four load-cell supports, a main controller, an OLED display, a rechargeable battery, and the enclosure. The pressure array measures spatial loading. The load cells provide total body mass.

Path	Sensing element	Read-out	Reported output
Pressure	634 FSR elements at $1\text{\,}\mathrm{cm}$ pitch	Analog multiplexer into the STM32F103RCT6 ADC	645-byte frame (Section 4 )
Mass	Four SC902 load cells	Dedicated channel	Total load, displayed body mass

Table 1: The two measurement paths. Neither shares a converter with the other.

Area	Standard or reference
Safety and EMC	KC, against KS C 9832:2023 and KS C 9835:2019
Emissions	Class B
Immunity	Electrostatic discharge, $\pm 4\text{\,}\mathrm{kV}$ contact and $\pm 8\text{\,}\mathrm{kV}$ air
Conformity	CE, FCC, and TELEC declarations of conformity; VCCI registration
Hazardous substances	RoHS 2011/65/EU with (EU) 2015/863, all ten restricted substances; assessed under IEC 63000:2016+AMD1:2022 with IEC 62321 methods
End of life	WEEE 2012/19/EU with (EU) 2024/884, category 5; rates under IEC/TR 62635:2012

Table 2: Certification and intellectual property of the FISICA Scale.

Item	Specification
Device size	$321\times 321\times 55$ mm
Pressure sensing	$22\times 29$ logical grid at $1\text{\,}\mathrm{cm}$ pitch, split into left and right $11\times 29$ regions; 634 physical FSR elements
Array read-out	Analog multiplexer into the sensor-controller ADC
Body-mass sensing	Four SC902 load cells on a separate channel; maximum specified load 180 kg
Sensor controller	STM32F103RCT6 (sensor PCB, FR4)
Main controller	ESP32-S3 (main PCB, FR4)

Table 3: FISICA Scale hardware specification, from the Care&Co. product specification.

Tier	Host	Compute	Role
Edge	AWS Seoul, t4g.medium	Ubuntu 24.04	HTTPS termination (Traefik), central configuration, central logging (Grafana, Loki, Promtail)
Production	On-premise, k3s v1.34	Control plane, plus $2\times$ (12 cores, $28\text{\,}\mathrm{GB}$ , NVIDIA RTX 5060 Ti $16\text{\,}\mathrm{GB}$ )	Thirteen microservices at two to three pods each
Development	On-premise, k3s, single node	8 cores, $25\text{\,}\mathrm{GB}$ , NVIDIA RTX 3070 $8\text{\,}\mathrm{GB}$	Same stack, one pod per service
State	Amazon RDS	PostgreSQL	Separate production and development databases, per-service schema

Table 4: Deployment tiers. The production and development clusters run the same stack on different GPUs, which is what makes the comparison in Section 9.4 an internal controlled contrast rather than a vendor claim.

Service output	Primary input	Returned information
Posture analysis	Frontal and lateral RGB images	Body keypoints, depth, a C7 landmark, and view-specific alignment indicators
Pressure analysis	FSR grid and mass channel	Pressure heatmap, left and right balance, regional loading, foot dimensions, and top classifier labels
Embodied view	Fused posture coordinates and the pressure image	An avatar driven to the measured parameters, with the pressure decal and the centre-of-gravity line registered to it
Footwear	Pressure observations and user constraints	Ranked shoes from the released catalog, matched features, exclusions, and an explanation trace
Exercise	Posture or pressure needs, goals, and safety constraints	Supported movements, instructions, exclusions, and permitted safety text

Table 5: FISICA service outputs and their inputs.

Figure 2: A decoded pressure frame in the

22\times 29

product layout. The dashed line marks the boundary between the two half-mats. The cell pitch is a physical constant, so foot lengths and widths follow from the grid without a camera-based scale reference.

Figure 3: Decoded and interpolated pressure frames for four of the nine class labels. Each panel shows both feet. The midfoot band is what separates the first three: a high arch (b) leaves forefoot and heel unconnected, a normal arch (a) leaves a narrow bridge between them, and a flat foot (c) loads the midfoot continuously. Panel (d) shows the asymmetry between feet that the left-right load ratio reports. These are development captures, not class prototypes, and the label is the classifier output rather than a clinical finding.

Figure 4: Pressure report for the normal example of Figure 3 . The panel gives the top class with its softmax value, an arch-level index, the left and right load split, and the three anatomical bands per foot as percentages of that foot’s own total. The rest of the report adds foot length and width in millimetres and a shoe size. The softmax value is not a calibrated probability and is not validated against a reference standard.

Configuration	AP	AP 50	AP 75	mOKS	[email protected]	Inst. det.	p50 (ms)
Deployed ONNX ( $224^{2}$ , fp16)	$0.633$	$0.864$	$0.681$	$0.689$	$0.960$	$1.000$	$62.8$
PyTorch, $224^{2}$ input (fp32)	$0.670$	$0.866$	$0.721$	$0.707$	$0.964$	$1.000$	$49.4$
PyTorch, native res. (fp32)	$0.729$	$0.857$	$0.790$	$0.770$	$0.977$	$1.000$	$54.2$
MediaPipe BlazePose (heavy)	$0.414$	$0.597$	$0.457$	$0.504$	$0.634$	$0.738$	$134.6$ †

Table 6: Keypoint estimation on the held-out split of

120

public COCO images and

168

person instances. Same images, protocol, and hardware in every row. [email protected] uses the bounding-box diagonal of Equation ( 1 ). “Inst. det.” is the fraction of ground-truth instances matched to a prediction. The first three latencies come from the interleaved run in Table 8 and are comparable. † MediaPipe ran separately on a CPU delegate, so its latency is not comparable to the GPU rows.

Figure 5: Accuracy of the served graph against alternatives on the same split. The served graph localizes

96.0\text{\,}\mathrm{\%}

of visible keypoints within [email protected] and matches every ground-truth instance. The gap to the on-device alternative is

0.326

PCK and

0.219

AP.

	Deployed ( $224\times 224$ , fp16)				Native res. (fp32)
Keypoint	$n$	mean (px)	median (px)	norm.	mean (px)	norm.
nose	145	7.83	2.36	0.0260	4.23	0.0155
left_eye	127	4.23	2.21	0.0196	4.64	0.0171
right_eye	129	7.21	1.89	0.0236	4.38	0.0156
left_ear	92	5.11	3.17	0.0161	6.31	0.0230
right_ear	106	9.76	3.18	0.0326	6.21	0.0215

Table 7: Per-keypoint error for the deployed configuration and for full-resolution inference of the same weights. “norm.” divides the mean pixel error by the ground-truth bounding-box diagonal.

n

is the number of matched visible instances of that keypoint.

Configuration	mean (ms)	std (ms)	p50 (ms)	p95 (ms)	p99 (ms)
Deployed ONNX ( $224^{2}$ , fp16)	$71.40$	$34.22$	$62.81$	$140.46$	$172.70$
PyTorch, $224^{2}$ input (fp32)	$53.70$	$17.51$	$49.44$	$88.87$	$109.56$
PyTorch, native res. (fp32)	$60.65$	$19.62$	$54.24$	$102.05$	$136.87$

Table 8: Interleaved latency of three configurations sharing weights. One process, rotating order per image,

120

images at

3

repetitions each, after

20

warm-up iterations per path. End-to-end, including preprocessing and transfer of results to host memory.

Stage	mean (ms)	std (ms)	p50 (ms)	p95 (ms)	p99 (ms)
Preprocess	$0.82$	$0.21$	$0.81$	$1.20$	$1.39$
Inference	$81.57$	$39.52$	$71.40$	$158.27$	$194.86$
Postprocess	$0.12$	$0.03$	$0.11$	$0.17$	$0.21$
End-to-end	$82.50$	$39.56$	$72.26$	$159.19$	$195.85$

Table 9: Stage-separated latency over

600

timed runs, after

20

discarded warm-up iterations, with device synchronization at every stage boundary. Component measurement, not a production service level.

Candidate instances	images	median latency (ms)
$\leq 1$	$19$	$66.3$
2–5	$29$	$65.5$
6–10	$27$	$83.6$
11–20	$29$	$90.7$
$>20$	$16$	$119.2$

Table 10: Inference latency by the number of candidate instances the graph returns. Per-image median over

5

repetitions,

120

images.

Configuration	Quantity	$n$	median	mean	p95	within $2\text{\,}\mathrm{\SIUnitSymbolDegree}$
Deployed ONNX ( $224^{2}$ , fp16)	shoulder tilt	159	3.16	12.40	54.06	32.1%
Deployed ONNX ( $224^{2}$ , fp16)	pelvic tilt	144	5.26	18.62	140.59	25.0%
PyTorch, $224^{2}$ (fp32)	shoulder tilt	159	3.12	10.65	34.48	36.5%
PyTorch, $224^{2}$ (fp32)	pelvic tilt	145	5.86	14.23	39.50	20.7%
PyTorch, native res. (fp32)	shoulder tilt	159	3.16	10.21	43.71	40.3%
PyTorch, native res. (fp32)	pelvic tilt	145	4.95	13.85	38.36	22.8%

Table 11: Absolute error of the two derived tilt angles, computed from predicted and ground-truth landmark pairs on the same instances. “within

2\text{\,}\mathrm{\SIUnitSymbolDegree}

” is the fraction of instances whose derived angle falls within two degrees of the reference. The mean and p95 follow a small population of large failures, so the median is the informative statistic.

Quantity	Pair separation (px)	$n$	median ( $\text{\,}\mathrm{\SIUnitSymbolDegree}$ )	p95 ( $\text{\,}\mathrm{\SIUnitSymbolDegree}$ )	reversed	within $2\text{\,}\mathrm{\SIUnitSymbolDegree}$
Shoulder tilt	$0$ – $40$	53	5.21	147.57	9.4%	20.8%
	$40$ – $80$	58	3.09	18.44	1.7%	34.5%
	$80$ – $160$	30	1.91	9.97	0.0%	50.0%
	$160$ – $320$	17	2.85	33.19	0.0%	29.4%
Pelvic tilt	$0$ – $40$	82	6.15	157.50	9.8%	18.3%
	$40$ – $80$	39	4.03	22.61	2.6%	38.5%

Table 12: Derived-angle error for the deployed configuration, binned by the ground-truth pixel separation of the landmark pair. “reversed” is the fraction of instances whose left and right landmarks are swapped.

Figure 6: Derived-angle error against subject scale. Median error falls and sign reversals disappear as the landmark pair separates. The pelvic index stays worse than the shoulder index at every scale, which follows the per-keypoint hip error in Table 7 .

Figure 7: Lateral captures with estimated keypoints. The trunk chain is the polyline that Equation ( 2 ) uses. The kyphotic subject shows a posterior convexity of the upper back and a head carried in front of the shoulder line. Faces are pixelated.

Figure 8: The extraction overlay. The frontal panel gives torso-normalised segment proportions. The lateral panel gives the sagittal parameters. In the kyphotic case the curvature moves upward: the per-node relative flexion

s_{2}

rises from

14\text{\,}\mathrm{\SIUnitSymbolDegree}

to

21\text{\,}\mathrm{\SIUnitSymbolDegree}

while

s_{1}

moves from

-18\text{\,}\mathrm{\SIUnitSymbolDegree}

to

-14\text{\,}\mathrm{\SIUnitSymbolDegree}

. A fixed-node metric misses this shape change. The two-line construction folds it into the

7.2\text{\,}\mathrm{\SIUnitSymbolDegree}

separation. This developer overlay is compiled out of release builds, so its labels are the internal Korean identifiers. In the lateral panel they read, from top, CVA, thoracic bend with node

s_{3}

, node

s_{2}

, and lumbar bend with node

s_{1}

.

Figure 9: The driven avatar after the loop converges. Upper Back and Low Back are measured on the avatar with the functions applied to the subject. The Neck Angle badge is pinned to the measured value (Section 7.6 ). The spine indicator changes colour above a threshold. Both subjects are near coronal-plane neutrality in the frontal views, which shows that the sagittal difference is not an artifact of global misalignment or subject rotation. Interface labels use plain language, because the reader is the subject.

Parameter	Normal	Kyphotic	$\Delta$
Thoracic two-line bend (subject)	$42.0\text{\,}\mathrm{\SIUnitSymbolDegree}$	$49.2\text{\,}\mathrm{\SIUnitSymbolDegree}$	$7.2\text{\,}\mathrm{\SIUnitSymbolDegree}$
Thoracic bend, avatar badge	$46\text{\,}\mathrm{\SIUnitSymbolDegree}$	$53\text{\,}\mathrm{\SIUnitSymbolDegree}$	$7\text{\,}\mathrm{\SIUnitSymbolDegree}$
CVA (subject)	$51.2\text{\,}\mathrm{\SIUnitSymbolDegree}$	$42.9\text{\,}\mathrm{\SIUnitSymbolDegree}$	$-8.3\text{\,}\mathrm{\SIUnitSymbolDegree}$ , more forward head
CVA, avatar badge †	$52\text{\,}\mathrm{\SIUnitSymbolDegree}$	$43\text{\,}\mathrm{\SIUnitSymbolDegree}$	$-9\text{\,}\mathrm{\SIUnitSymbolDegree}$
Lumbar two-line bend (subject)	$17.6\text{\,}\mathrm{\SIUnitSymbolDegree}$	$14.1\text{\,}\mathrm{\SIUnitSymbolDegree}$	$-3.5\text{\,}\mathrm{\SIUnitSymbolDegree}$
Lumbar bend, avatar badge	$12\text{\,}\mathrm{\SIUnitSymbolDegree}$	$12\text{\,}\mathrm{\SIUnitSymbolDegree}$	$0\text{\,}\mathrm{\SIUnitSymbolDegree}$

Table 13: Matched comparison of two records. Rows marked

\dagger

come from display paths under revision (Section 7.6 ) and are not independent evidence. The CVA badge is pinned to the measured value each frame, so its agreement with the subject row is constructed. The shoulder badge comes from a separate indicator geometry.

n=2

.

Channel	Drive	Display	Note
Thoracic bend	Closed-loop	Solver function	One definition end to end
Lumbar bend	Closed-loop	Solver function	Displays $12\text{\,}\mathrm{\SIUnitSymbolDegree}$ on both records; range and saturation marker under review
Lateral bend, trunk lean	Closed-loop	Solver function	One definition end to end
Craniovertebral angle	Closed-loop	Separate indicator, offset each frame to the measured value	The drive carries the measurement; the badge repeats the input, so it is not convergence evidence
Round-shoulder protraction	Tuned gain	Not displayed	No avatar-side measurement; no number reaches the reader
Shoulder level	Per-side drop relative to C7, scaled by avatar shoulder width	Separate indicator geometry	Three definitions not yet collapsed to one

Table 14: Channel status. “Closed-loop” means the avatar is measured with the function used on the subject and solved to match. Rows marked

\dagger

in Table 13 correspond to the two display paths that are not yet on one definition.

Figure 10: Left: the concept graph. An observation creates a functional need directly, or reaches one through a state or pattern along a MAY_INDICATE edge that cannot itself contribute to a score. A need is supported by shoe and exercise features, which derive from typed item facts. Right: the request path. Authorization, record scope, and stale or out-of-range assertions are resolved before the graph is entered, hard exclusions are applied before any scoring, and the language model receives only the final candidates and the evidence permitted to explain them.

Node	Role	Example
MeasurementRecord	Source measurement used	record identifier, capture time
Observation	Value computed from the measurement	forefoot load share, shoulder alignment
StateTendency	Tendency the model suggests, not a diagnosis	flat-foot tendency, high-arch tendency
Pattern	Combination of observations or change over time	forward head with round shoulder
FunctionalNeed	What an item must support	forefoot pressure redistribution
ShoeFeature	Derived shoe function	heel cushioning, stability support

Table 15: Node and relation inventory of the domain ontology. The graph is typed: an evaluator accepts only the need identifiers it supports, so an arbitrary string cannot enter as a functional need.

Attribute	Meaning	Items	Coverage
arch_support	Arch-support class	699	100%
forefoot_width_mm	Forefoot width at reference size	699	100%
removable_insole	Insole detachable	699	100%
orthotic_friendly	Accepts a functional insole	699	100%
weight_g	Mass	688	98.43%
drop_lab_mm	Heel-to-forefoot height difference	674	96.42%

Table 16: Attribute completeness across the

699

-model catalog. Coverage enters the score directly through

q_{f}

in Equation ( 4 ), which is what keeps a sparsely measured item from outranking a fully measured one on the same nominal strength.

Observation condition	Functional need	Principal shoe feature
Forefoot load $\geq 40\%$	Forefoot pressure redistribution	Forefoot cushioning
Rearfoot load $\geq 42\%$	Heel-impact accommodation	Heel cushioning
Midfoot load $\geq 30\%$ and flat-foot confidence $\geq 0.15$	Midfoot support	Stability support
Forefoot load $\geq 40\%$ and high-arch confidence $\geq 0.20$	Reinforced redistribution	Cushioning and space
Rearfoot load $\geq 42\%$ and high-arch confidence $\geq 0.20$	Reinforced heel accommodation	Heel cushioning

Table 17: Active plantar-pressure conditions in the development footwear scorer. Percentages are fractions of the load on that foot. Confidences are softmax outputs of the classifier in Section 4 .

Domain	User relation	Effect on score
Footwear	Preferred brand	$+2.00\times$ confidence
	Preferred product	$+1.25\times$ confidence
	Preferred attribute	$+0.75\times$ confidence $\times$ strength $\times$ coverage, capped at $1.5$ per candidate
	Recorded fit issue	$-100\times$ confidence
Exercise	Matching goal	$+0.20\times$ confidence
	Preferred movement	$+0.75\times$ confidence

Table 18: Personalization terms, applied after the measurement score and after hard exclusions. Each is scaled by the confidence of the stored user assertion. The shoe attribute term is additionally scaled by feature strength and coverage, so a preference cannot promote an item whose supporting data is thin.

Figure 11: Ranked candidates returned for the measurement of Figure 4 . The match percentage is a catalog rank from Equation ( 4 ), not a probability of benefit. The size follows the measured foot length of Section 4 . Inventory and size-specific internal dimensions are not in the catalog, so a result is not a stock or fit guarantee.

Figure 12: Production median response time by feature, service level, logarithmic axis. Basic read features occupy the left decade, single-model AI analysis the middle, and agent recommendation the right.

Figure 13: Stage decomposition of the shoe-recommendation flow, production, 30 trials, stage medians. Blue stages are rule-based system work. Orange stages are language-model generation.

Feature	Environment	$n$	Mean $\pm$ SD	95% CI	Median	p95	Min / Max
Shoe recommendation	Production	30	$2.45\pm 1.43$	[1.92, 2.98]	2.16	3.61	1.58 / 9.38
Shoe recommendation	Development	30	$1.93\pm 0.89$	[1.60, 2.26]	1.60	3.19	1.30 / 5.79
Exercise recommendation	Production	30	$3.74\pm 3.55$	[2.41, 5.07]	2.26	13.26	1.74 / 14.47
Exercise recommendation	Development	30	$2.03\pm 0.14$	[1.98, 2.08]	1.99	2.27	1.84 / 2.41

Table 19: End-to-end latency at the service level, 30 trials per cell, in seconds. 95% CIs are

t

-distribution intervals of the mean at

\mathrm{df}=29

.

Stage	Shoe prod.	Shoe dev.	Exercise prod.	Exercise dev.
(1) Admission, validation, quota	0.31	0.25	0.33	0.25
(2) Language-model planning	0.13	0.13	0.11	0.10
(3) Recommendation matching	0.36	0.15	0.38	0.24
(4) Time to first answer token	0.78	0.73	1.07	0.62
(5) Answer streaming complete	0.39	0.36	0.31	0.76
System subtotal (1 to 3)	0.78	0.53	0.84	0.59

Table 20: Stage-level latency, medians in seconds. Stages 1 to 3 are the rule-based system portion. Stages 4 and 5 are language-model generation.

Figure 14: (a) Recommendation response-time distribution. The production tails are generation-stage outliers, not system-stage outliers. (b) Real-usage median ML inference time on the production RTX 5060 Ti

16\text{\,}\mathrm{GB}

against the development RTX 3070

8\text{\,}\mathrm{GB}

, same code.

ML feature	Environment	$n$	Mean	Median	p90	p95	Min / Max
Plantar-pressure analysis	Production	199	0.56	0.45	0.82	1.52	0.25 / 2.46
Plantar-pressure analysis	Development	232	0.43	0.28	0.79	1.55	0.14 / 2.64
Body-composition report OCR	Production	9	n/a	2.45	n/a	n/a	0.35 / 4.64
Body-composition report OCR	Development	544	14.49	17.63	25.92	27.66	0.44 / 83.74
Composite measurement analysis	Production	351	3.10	1.30	2.19	13.17	0.77 / 48.82
Composite measurement analysis	Development	112	6.97	9.91	11.93	12.13	0.39 / 16.84

Table 21: ML inference statistics, 90-day real-usage census, in seconds. Production uses an RTX 5060 Ti

16\text{\,}\mathrm{GB}

. Development uses an RTX 3070

8\text{\,}\mathrm{GB}

. “n/a” marks statistics withheld for

n<30

.

Feature	Environment	$n$	Mean $\pm$ SD	95% CI	Median	p95	Min / Max
Measurement, pressure only	Production	30	$0.61\pm 0.11$	[0.57, 0.65]	0.58	0.86	0.48 / 0.93
Measurement, pressure only	Development	30	$0.43\pm 0.03$	[0.42, 0.44]	0.43	0.49	0.38 / 0.50
Measurement, pressure+pose	Production	30	$3.04\pm 2.23$	[2.21, 3.87]	2.70	3.41	2.02 / 14.61
Measurement, pressure+pose	Development	29	$2.87\pm 2.78$	[1.81, 3.93]	2.43	4.34	1.54 / 16.74

Table 22: Controlled measurement experiment on 2026-08-24: fresh accounts, identical fixed inputs, 30 trials per feature and environment, service level, in seconds.

Ours (production)	Published baseline	Source	Fairness note
General REST APIs, p50 $23\text{\,}\mathrm{ms}$	$100\text{\,}\mathrm{ms}$ threshold for instantaneous response	[ 20 , 10 ]	Four times of headroom below the classic threshold
Agent time to first token, $1.59\text{\,}\mathrm{s}1.96\text{\,}\mathrm{s}$ , including tool orchestration	Median TTFT of comparable reasoning-class LLM APIs, $2.92\text{\,}\mathrm{s}$ , model only	[ 4 ]	Ours includes gateway and tool execution; the baseline is a model-only API
Agent end-to-end, $2.16\text{\,}\mathrm{s}2.26\text{\,}\mathrm{s}$	Iterative tool-calling agents, $11.3\text{\,}\mathrm{s}38.6\text{\,}\mathrm{s}$ per query, and $2.8\text{\,}\mathrm{s}5.9\text{\,}\mathrm{s}$ after optimization	[ 13 ]	Peer-reviewed agent system; the task domain is graph QA
Document OCR, $3.83\text{\,}\mathrm{s}$ per report sheet	Commercial cloud OCR APIs over 500 invoices: $3\text{\,}\mathrm{s}4\text{\,}\mathrm{s}$ , $4\text{\,}\mathrm{s}5\text{\,}\mathrm{s}$ , and $4\text{\,}\mathrm{s}6\text{\,}\mathrm{s}$ for three vendors	[ 33 ]	Same unit, one document, end-to-end; vendor-run benchmark, so the vendor’s own row is the favourable one
Composite measurement analysis, $2.1\text{\,}\mathrm{s}2.9\text{\,}\mathrm{s}$	Within the $10\text{\,}\mathrm{s}$ limit for holding attention on a task	[ 20 ]	Threshold, not a competing system

Table 23: Our measurements against published baselines, with the measurement layer stated in each row.

Requirement	Specified	Measured	Reported in
Keypoint localization (PCK)	$\geq 40\%$	$96.0\text{\,}\mathrm{\%}$ on the held-out split	Section 6
API response time	$\leq$ 450\text{,}\mathrm{ms}$$	$23\text{\,}\mathrm{ms}$ median, $249\text{\,}\mathrm{ms}$ p95, production	Section 9

Table 24: Product-specification requirements against measured values. PCK uses the bounding-box diagonal normalizer of Equation ( 1 ), stated so the comparison can be checked.

Item	Approved value
Approval number	P01-202512-01-047
Review outcome	Approved, reviewed 29 December 2025
Approval valid to	28 December 2026
Study period	From approval to 31 December 2026
Study type	Human-subject research, survey research
Study form	Single site

Table 25: Approved terms of protocol P01-202512-01-047. The board classified the study at its lowest risk tier and required written consent, which are the conditions the data collection now runs under.

Figure 15: Paired-view annotation concept. One surface-landmark schema is shown with frontal and lateral spinal radiographs and the matching RGB captures. The diagram records intended landmark correspondence across modalities. It does not treat their pixel coordinates as interchangeable. Use of this participant image in a public manuscript remains conditional on confirmation that the consent and de-identification scope permits publication.

FISICA: A Deployed Service for Plantar-Pressure and Posture Assessment with Ontology-Grounded Recommendation

Abstract

Figures & tables

Appendix

3D Avatar Generation

A Research Prototype for Closed-Loop Generative Design of Customized Foot Orthoses via Semantic-Physics Alignment

Robust Real-Time Monocular Human Pose Estimation with Insole-Based Sensor Fusion

PhysioAI: Clinical Knowledge-Guided Semantic Supervision for Skeleton-Based Physiotherapy Action Recognition

Abstract

3D Avatar Generation

Explore similar work

A Research Prototype for Closed-Loop Generative Design of Customized Foot Orthoses via Semantic-Physics Alignment

Robust Real-Time Monocular Human Pose Estimation with Insole-Based Sensor Fusion

PhysioAI: Clinical Knowledge-Guided Semantic Supervision for Skeleton-Based Physiotherapy Action Recognition