Behind the scenes

A production line that never sleeps.

Every change to DecisionEngine is built, independently reviewed, measured and replayed against historical training days before it reaches a device. This page shows the method — not the recipe.

Why all this effort? Two things drive it: I don't want to lock anyone into a closed ecosystem — DecisionEngine connects to whatever Apple Health and as many other providers as possible offer, vendor-neutral. And I believe software should grow in small, constant steps instead of big leaps every two years — what follows is the machinery that makes that possible without losing quality.

The development loop: use, signal, sorting, work order, build, release — and back to use. Use Signal Sorting Work order Build Release Almost daily a new version

01 — Counted, not estimated

The scope

Every number here was counted from the source tree — not rounded, not flattered.

717
app source files
12 311
automated tests
2 906
reference images of the interface
66
automations running around the clock
419
checking and self-test scripts
59
beta builds since April
747
logged decisions with their reasoning
13
binding architecture decisions

Counted on 2026-09-05all values taken from the source tree when the page was built.

Before every upload, a subset of about 4,300 tests runs in just over three minutes; the full run including all athlete simulations takes over an hour and runs overnight.

02 — The path of a change

From idea to your iPhone

This flow runs unattended — except where a genuine product decision is due. That one belongs to a human.

  1. A task appears

    From tester reports, from the backlog — or because one of the automations found something wrong by itself.

  2. The dispatcher picks it up

    Every task gets its own isolated working copy of the project. Two tasks can never get in each other’s way.

  3. The tool follows the risk

    A typo gets a small, fast model. Anything touching the decision core or safety gets the strongest one — with explicitly extended thinking time. When in doubt, always the stronger one.

  4. Built and checked on the simulator

    Never “looks right”: compiled, run, measured. A failing test means back to work — never “switch the test off”.

  5. An independent adversarial reviewer

    A second, separate process reads the proposal with the explicit job of tearing it apart — with no knowledge of the author’s reasoning. Whoever built it does not review themselves.

  6. The gates

    Pixel-by-pixel comparison of the interface, language checks in German and English, design system, accessibility — and for the decision core, a replay against historical days: does the change move recommendations? If so, it goes to the human.

  7. Merge, build, ship

    The release train runs at night: full test pass, build, upload to TestFlight. If anything breaks, it does not depart — better no build than a broken one.

03 — The closed loop

The loop closes by itself

The end of the chain is its beginning again. What a tester reports gets collected, sorted, turned into a task, into code, into a build — and lands back with that same tester as a new version.

01
Beta feedback is collected automatically
02
Sorted and de-duplicated — the same issue twice is recognised as the same
03
Becomes a task with acceptance criteria
04
Built, reviewed, through the gates
05
The nightly release train builds and uploads
06
The new version reaches the testers

And then from the top. One watcher even remembers whether the same complaint comes back — in which case it simply was not fixed, whatever the ticket said.

04 — Security

The best protection is what does not exist

There is no account, no server and no database holding your health data. That removes the entire class of incidents that regularly hits other providers.

  • No central prize. There is no place where many people’s data sits together — so there is none that could leak.
  • No foreign components. Neither advertising nor analytics libraries from third parties ship in the app. What is not shipped cannot quietly listen in.
  • Access keys in the keychain. If you connect a training service, its access key lives solely in the device’s secure keychain — not in a file, not in the cloud.
  • No transport-security exception. The app has granted itself no permission for unencrypted connections — not even “just for testing”.
  • Privacy manifest for app and widget. Apple’s machine-readable declaration of which data is used for what — filed for both components, not just the main app.
  • Nightly security audit. A dedicated automation searches every night for known vulnerability patterns and files what it finds as a task.
  • Secret scan before every release. No build ships without the tree being searched for accidentally committed credentials.

05 — Language

Every version complete in both languages

Not “German will follow later”. German and English rank equally, in every single release — enforced, not hoped for.

  • 2,565 text entries, every one maintained in both languages. , jeder in beiden Sprachen gepflegt.
  • A checker blocks hard-wired text. Anyone writing a sentence straight into the code instead of the string catalogue does not get through the gates — there is no “just this once”.
  • The largest type size is checked too. The reference images cover German at maximum system font size — exactly where long German words otherwise tear interfaces apart.

06 — The house rule

A check has three outcomes, not two

The most expensive failure in an automated pipeline is not a check that raises the alarm. It is one that reports “fine” without having measured anything at all.

Passed
measured — and fine.
Failed
measured — and not fine.
Unmeasured
could not measure. Its own outcome — never silently collapsed into one of the other two.

Prove it by putting the bug back

A new check counts as accepted only once it demonstrably re-finds the defect it was built for — after temporarily undoing the fix. A check that never fired has proven nothing.

This rule was born from damage: on a single day, six checks were found that had silently turned “not measured” into “fine”. It has been the most binding rule here ever since.

07 — Why this concerns you

Discipline is not an end in itself

A recommendation is only as good as its verification

A training decision resting on an unnoticed calculation error is worse than none at all. Hence the effort.

No server also means: less that can go wrong

There is no service of ours where your health data could sit. What does not exist cannot leak.

Every recommendation is traceable

On request the app shows you which signals led to its suggestion — down to the individual values. No “trust me”.

08 — In fairness

What is deliberately absent here

This page shows the method, not the recipe. How the engine weighs signals, how it learns from your feedback and how its athlete profile forms — that stays our craft.

The sports-science foundation, by contrast, is fully open — every constant with its source in the literature, pinned by a dedicated test. Anyone who wants to check it can trace it back to the original paper.