Calibrezi
You set a reference position for the session.
Posture & focus sessions Prototype in development
AirPosture, our posture and focus project, explores the use of motion sensors in compatible headphones. Head position is reported against a personal calibration, during a work session.
AirPosture
You set a reference position for the session.
The system tracks the change in orientation relative to that reference.
A discreet signal can draw attention to a persistent deviation.
Work sessions with a timer and break moments.
Feedback relative to calibration, using movement data.
We are exploring interactions between headphones, phone and desktop apps.
AirPosture is a prototype. Measuring head orientation is not a diagnosis of the spine, and operation depends on hardware and validation on compatible devices.
AirPosture in detail
AirPosture uses the motion sensors in AirPods for one thing: how much your head has dropped relative to a position you calibrate at the start of a work session. When the deviation persists, you receive a discreet vibration. The rest of the app is a focus timer with breaks.
It does not measure the spine and does not try to. AirPods provide head orientation — pitch, roll, yaw — and nothing about the shoulders, thorax or back curvature. A lowered head with a straight back and a curved back with the gaze compensated upwards look the same to this sensor. The app says this upfront, because that is the difference between a useful tool and a false promise.
Uses `CMHeadphoneMotionManager`, Apple’s interface that exposes the sensors in the headphones. It delivers attitude (quaternion, pitch, roll, yaw), rotation rate, gravity, acceleration and `sensorLocation` — which AirPod is sending the data. The measured rate is around 25 Hz. A watchdog checks the stream every second: if no sample has arrived for more than 2.5 seconds, it restarts the connection and says why.
The quick version takes three seconds: stand upright, and the app keeps the median of your pitch. The guided version has five phases of three seconds each — neutral, chin down, look up, rotate left, rotate right — and learns the pitch sign for your headphone model instead of guessing it, then recalculates thresholds based on your real movement amplitude. The calibration report also says why it was poor: too few samples, head moved, laptop moved, movement too small up or down.
Below 7° from calibration means upright. Between 7° and 13° is drifting. Above 13° held for three seconds triggers the haptic alert. There is also a fourth threshold, in the other direction: above 10° up means “head raised”, so the app does not confuse a look at the ceiling with bad posture. The signal is exponentially smoothed with α = 0.15, so a normal head movement does not trigger anything.
Timer of 5, 15, 25, 45 or 60 minutes, with start, pause and reset. The posture alert has a default grace period of 300 seconds between notifications, AirPods disconnect 90, and tracking stream degradation 120 — a single event cannot fill the screen. At the end, the session reports the percentage of good posture, the number of alerts and the number of samples.
There is a second target, `AirPostureMac`: menu bar, dashboards, 3D scene, diagnostics, health history and an acoustic laboratory. It builds locally, but it is not a finished product. In the same repository there are three separate iOS research apps — walking, interview response dynamics and an ear-EEG test bench — each with its own onboarding, all unvalidated on hardware.
Data and operation
From exploration to implementation
AirPods Pro, AirPods 3 and later, AirPods Max or Beats with H1/H2 chip. AirPods 1 and 2 do not have the necessary sensors and will never work. Availability is confirmed at runtime, not assumed from the model.
We run the guided calibration in five phases and read the quality report. If the up-down amplitude is too small or the head has moved too much, the calibration is repeated — the personal thresholds are derived from it, so a poor calibration spoils everything that follows.
7°, 13° and the three seconds of grace are the starting point, not a physical constant. The guided calibration moves them into bounded ranges — slouching between 5° and 9°, hunching between 10° and 18° — based on the person's actual amplitude.
An alert that becomes annoying is turned off, so it helps no one. It is checked whether the five-minute respite suits the way you work and whether the vibration is discreet enough in the presence of other people.
With AirPods. It uses `CMHeadphoneMotionManager`, the Apple interface that exposes motion sensors from the headphones, at around 25 Hz. It works with AirPods Pro, AirPods 3 and later, AirPods Max and Beats with H1 or H2 chip. AirPods 1 and 2 do not have the necessary sensors. Other headphones do not provide this data.
No, and it does not try to. It measures one thing only: how much the head has tilted relative to a position you calibrate at the start of the session. Under 7° means upright, between 7° and 13° is slouching, and above 13° held for three seconds triggers a discreet vibration. Above 10° upwards is "head raised", not a problem. That is all.
Because of distribution, not code. The application compiles, passes 160 tests and installs and launches on the iPhone simulator, but `DEVELOPMENT_TEAM` is empty in the project specification, so a signed version for a real phone has never been built. Until that is resolved and the sensor flow is checked on physical AirPods, it remains a prototype — and we call it that.
No. `CMHeadphoneMotionManager` does not have its own background mode, and iOS suspends the application when it leaves the foreground. There is a common trick — playing silent audio to keep the process alive — and we deliberately excluded it: it contradicts rule 2.5.4 of Apple's review guidelines. The session runs with the application open. An "all-day coach" would require a different architecture and a discussion with App Review.
The flow continues — `sensorLocation` says which AirPod is sending the data, and the app has capture scenarios for both, left only and right only. But `sensorLocation` does not prove that the respective earbud is actually in the ear, and the transition both → left → right → both has not been verified on real hardware. It is on the not validated list, not the works list.
They stay on the phone. The app’s data policy marks them `localOnly`, and raw samples are automatically deleted after 14 days, aggregates after one year. They are not written to HealthKit — there is no standard type for head posture, and the app does not force-convert them into steps or anything else to make them fit. There is also full deletion.
No. We analysed both questions and wrote the answer in the project documentation. A brain scan is not possible with AirPods hardware and public interfaces, and a “lie detector” does not have sufficient scientific basis — the requirement was reformulated as observing response dynamics, which describes what is seen and does not issue a truth verdict.
Illustrative example
A use case, without client data or attributed commercial results.
You put on the AirPods, open the app, choose 25 minutes and stand straight for three seconds while calibration runs. The app stores the median of your pitch as the reference.
At ~25 Hz, each sample is exponentially smoothed (α = 0.15) and compared with the reference. Below 7° — green. Between 7° and 13° — yellow, no alert. Above 13° held for three seconds — vibration. The grace timer starts: the next posture alert cannot come sooner than five minutes.
At the end you see the percentage of time spent in good posture, the number of alerts and the number of samples. Nothing leaves the phone; raw samples are deleted after 14 days.
What is required:AirPods with motion sensors (Pro, 3+, Max or Beats H1/H2), an iPhone with iOS 17 or newer, the app in the foreground and the Motion & Fitness permission granted. It does not work on the simulator — there the interface does not return data.
Collaboration possibilities
Exploring a pilot for habits and personal feedback. Individual data do not by default become tools for employee evaluation.
We define a pilot around a real process: users, data, integrations, costs and acceptance criteria. Expansion follows after evaluating the result.
We establish the requirements for accessibility, hosting, data protection and interoperability. Any connection to AGE or STISC services requires validation of eligibility, access and approvals.
These are adaptation scenarios, not statements about existing contracts or partnerships. The proposed functions are confirmed within the project scope.
Discuss a pilotTell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.