Tydlig genom Fokus

17 december 2025 · 18 minuter läsning

Denis Tumpic

Storinquisitören vid Technica Necesse Est

Anders Misstagshack

Biohackare Full av Misstag

Gen Gast

Biohackare Gast i Gener

Krüsz Prtvoč

Latent Invocation Mangler

Featured illustration

“De mest kraftfulla experimenten är inte de som samlar mest data---utan de som ställer det tydligaste frågan med minsta möjliga kod.”

Det här dokumentet är inte en guide till att köpa sensorer eller ladda ner appar. Det är ett manifest för biohackare som vägrar drunkna i brus. Om du någonsin har tillbringat 40 timmar på att konfigurera en Fitbit-till-Notion-pipeline bara för att upptäcka att datan inte sa något nytt---så är du på rätt plats. Vi avvisar komplexitet som en dygd. Vi kräver matematisk rigor, arkitektonisk resilience och minimal kod. Vi behandlar din biologi inte som en svart låda att utvinna data från, utan som ett system som ska förstås---genom eleganta, bevisbara och extremt effektiva instrument.

Detta är filosofin bakom Tydlig genom Fokus: att riktig insikt uppstår inte från volym, utan från precision. Från minimering av variabler till deras väsentliga form. Från kod som är så enkel att den kan verifieras av en enda människa på mindre än 10 minuter. Från system som kör i år utan att krascha, eftersom de är byggda på matematisk sanning---inte hackar.

Vi skriver detta för DIY-biohackaren: den som bygger sin egen blodsockermätare med en Raspberry Pi och ett reagensstreck. Den som kalibrerar sin sömnspårare med aktigraphi och kortisolsalivtester. Den som vet att den mest värdefulla datapunkten inte är den med högsta upplösning---utan den som förändrar ditt beteende.

Låt oss bygga system som håller. System som inte kräver doktorander för att underhålla. System där koden är kortare än din hypotes.

Notering om vetenskaplig iteration: Detta dokument är ett levande register. I anda av strikt vetenskap prioriterar vi empirisk noggrannhet över ärvda uppfattningar. Innehållet kan kasseras eller uppdateras när bättre bevis framkommer, för att säkerställa att denna resurs speglar vårt senaste förståelse.

Problemet: Dataöverbelastning, insiktsbrist

Modern biohacking drunknar i data.

Du spårar:

Hjärthastighetsvariabilitet (HRV) från din Oura-ring
Blodsocker via kontinuerliga monitorer (CGM)
Sömnstadierna från wearable
Antal steg, VO₂ max, hudtemperatur, kortisolutslag, tarmmikrobiom-diversitet via avföringstester
Ljusexponering från blåljusmätare
Stämningsskattningar via 7-punkts Likert-skala
Andningsfrekvens, HRV-kohärens, till och med EEG-baserade alfa-vågor

Och ändå---vad vet du?

Du har 12 instrumentpaneler. 37 CSV-filer. En Notion-databas med 400+ poster. Du har tillbringat 217 timmar på att samla data under det senaste året. Men din sömnkvalitet? Forfarande osäker. Dina energidal? Oklara. Dina ångestutbrott? Inget mönster hittat.

Detta är dataöverbelastningsparadoxen: mer data → mindre tydlighet. Flervärder verktyg → färre insikter.

Varför?

För att data utan struktur är brus.
För att komplexa system döljer orsakssamband.
För att du inte kan optimera något du inte kan modellera.

Den genomsnittliga biohackaren tillbringar 85 % av sin tid på att hantera verktyg, inte tolka resultat. De är ingenjörer i dataflöden---inte vetenskapsmän om sig själva.

Vi föreslår en radikal vändning: Sluta samla mer. Börja bygga mindre.

Huvudperspektiv 1: Grundläggande matematisk sanning --- Kod måste härledas från bevisbart korrekta grundvalar

Irrationell tro på “Det fungerar på min dator”

Biohackare bygger ofta system som fungerar---tills de inte gör det.

“Mitt sockermodell förutsade min eftermiddagskollaps i tre veckor. Sedan började den ge NaN-värden efter en firmware-uppdatering.”

Detta är inte en anomaly. Det är den oundvikliga följden av ad-hoc-kod---skript som är ihopsatt från Stack Overflow, kopierade TensorFlow-modeller, ogiltiga statistiska antaganden.

Inom mjukvaruutveckling har vi ett ord för detta: teknisk skuld. I biohacking? Vi kallar det “experimentellt brus”.

Men här är sanningen: biologiska system följer matematik. Glukosmetabolism följer Michaelis-Menten-kinetik. Circadiana rytmer styrs av differentialekvationer. HRV är en tidsserie med autokorrelationsstruktur. Detta är inte metaforer---de är bevisbara, härledbara sanningar.

Om din kod inte speglar dessa sanningar, är den inte en modell. Den är en turistgissning.

Exempel: Glukosförutsägningsmodell

Antag att du vill förutsäga din 2-timmars postprandiala sockerökning efter att äta en banan.

Dåligt tillvägagångssätt:

# DÅLIG: Heuristisk, ingen matematik
def predict_glucose(banana_weight):
    if banana_weight > 100:
        return 120 + random.uniform(-15, 15)
    else:
        return 95 + random.uniform(-10, 10)

Detta är inte vetenskap. Det är astrologi med en CSV.

Gott tillvägagångssätt:
Använd Glukos-Insulin-modellen (GIM), en förenklad version av Bergmans minimalmodell:

\frac{dG}{dt} = -k_1 \cdot G(t) + D(t)

\frac{dI}{dt} = -k_2 \cdot I(t) + k_3 \cdot (G(t) - G_b)

Där:

$G(t)$ : plasmasockerkoncentration
$I(t)$ : insulinkoncentration
$D(t)$ : sockerupptagningshastighet från måltid ( härledd från kolhydratinnnehåll)
$G_b$ : basalt socker
$k_1, k_2, k_3$ : fysiologiska konstanter (kalibrerade via n=1-experiment)

Din kod måste implementera dessa ekvationer---inte gissa dem.

Matematisk sanning är den enda anti-fragila grundvalen i biohacking.

Om din modell är härledd från första principer, kommer den att generalisera över måltider, dagar och till och med individer---med korrekt kalibrering. Annars? Den bryts med nästa banan.

Varför detta är viktigt för DIY-biohackare

Du behöver inte en doktorsexamen för att härleda dessa ekvationer.
Du behöver förstå dem.
Öppen-källkods-bibliotek som PyGIM tillhandahåller verifierade implementationer.
Din kod blir verifierbar. Inte bara “den fungerar”, utan “här är varför den fungerar.”

Detta är den första pelaren: Kod måste vara matematiskt härledd. Inte empiriskt hackad.

Huvudperspektiv 2: Arkitektonisk resilience --- Den tysta lovan om decenniumslånga system

Ditt system bör överleva ditt intresse

De flesta biohacking-uppställningar dör inom 6 månader.

Sensorbatteriet dör.
API:n ändras.
Python-skriptet bryts av en ny OS-uppdatering.
Du glömmer hur du kör det.

Detta är inte ett misslyckande. Det är design.

Vi kräver arkitektonisk resilience: system som kör i 5, 10 eller till och med 20 år utan ingripande.

Hur?

Princip 1: Inga externa beroenden

Undvik moln-API:er (t.ex. Google Fit, Apple Health).
Undvik proprietära SDK:er.
Använd öppen hårdvara (t.ex. OpenBCI, Arduino-baserade sensorer).
Lagra data lokalt på SD-kort eller krypterade USB-minnen.

Din data är ditt mest värdefulla tillgång. Lämna inte dess vård över till ett företag som kan stänga ner om två år.

Princip 2: Tillståndsfri, idempotent bearbetning

Din analyspipeline måste vara idempotent: att köra den två gånger ger samma resultat.

# GOTT: idempotent skript
./analyze --input /data/glucose_2024.csv --output /results/insulin_response.json

# DÅLIG: tillståndsfylld, fragil
./analyze --token abc123 --last-run 2024-05-17

Om ditt skript bryts kan du köra om det från rådata. Inget dolt tillstånd. Inga databasmigrationer.

Princip 3: Hårdvaruabstraktionslager (HAL)

Bygg ett HAL mellan dina sensorer och din kod.

# Abstrakt sensorgränssnitt
class GlucoseSensor:
    def read(self): raise NotImplementedError

class NovaGlucoseMeter(GlucoseSensor):
    def read(self):
        # Prata med seriell port
        return float(serial.read().strip())

# Din modell vet bara: GlucoseSensor.read()

Nu, om din Nova-mätare dör? Byt ut mot en FreeStyle Libre-läsare. Ändra en klass. Inte 12 skript.

Princip 4: Noll körningsfel

Ditt system måste aldrig krascha under datainsamling. Aldrig.

Använd ändliga tillståndsautomater (FSM) för sensorkontroll.
Omsluta varje I/O-operation i try/except med gracefully degradation.
Logga fel till en roterande fil---inte stdout.

# Exempel: Robust sensorkontrollloop
def run_sensor_loop(sensor, log_file):
    while True:
        try:
            value = sensor.read()
            with open(log_file, 'a') as f:
                f.write(f"{time.time()},{value}\n")
        except Exception as e:
            log_error(e, log_file)
            time.sleep(60)  # Vänta och försök igen
        time.sleep(30)  # Prova var 30:e sekund

Resilience är inte en funktion. Den är baslinjen.

Ditt system måste vara som en pacemaker: tyst, pålitlig, oförstörlig.

Huvudperspektiv 3: Effektivitet och resursminimalism --- Den gyllene standarden

CPU, minne, ström---Dina tre mest värdefulla resurser

Du tror att din Raspberry Pi 4 är “kraftfull”. Den är det inte.

Den använder 3,5W när den är i vila. Din telefon? 0,8W i djup sömn.

Din dator? 15--45W.

Om du kör en full Linux-skrivbordsmiljö med Docker, Node.js och 12 webbläsarflikar för att övervaka ditt socker---du slösar energi.

Men viktigare: du slösar kognitiv bandbredd.

Effektivitetshierarkin

Nivå	Resursanvändning	Kognitiv belastning	Exempel
1 (Dåligast)	Hög CPU, högt minne, molnberoende	Mycket hög	Dockeriserad Python + Grafana + InfluxDB
2	Medel CPU, lokal DB	Medel	Python-skript med SQLite + Matplotlib
3 (Ideal)	Låg CPU, lågt minne, inga beroenden	Minimal	C-program som läser seriell port → CSV → gnuplot

Fallstudie: Glukosövervakningssystem

Metod	CPU-användning	Minne	Starttid	Underhållskostnad
Docker + Python + Grafana	45% CPU, 800MB RAM	12 min	$300/år (moln)
C-program + SQLite + gnuplot	2% CPU, 1,5MB RAM	3s	$0/år, 2h/år underhåll

C-versionen:

Kör på en $5 ESP32.
Loggar till SD-kort.
Behöver ingen internetanslutning.
Kan kompileras en gång, distribueras för alltid.

Effektivitet handlar inte om att spara pennor. Den handlar om att bevara din uppmärksamhet.

När ditt system använder 2% CPU glömmer du att det finns. När det använder 45% blir det en plikt.

Energieffektivitet = Beteendekonsekvens

Om din enhet tar slut på batteriet efter två dagar, kommer du inte att bära den. Om den håller i 6 månader på en enda knappcell? Du glömmer att den finns---och din data blir naturlig, inte tvungen.

Minimal resursanvändning → högre följsamhet → bättre data.

Huvudperspektiv 4: Minimal kod & eleganta system --- Proxyn för mänsklig förståelse

Antal kodrader (LoC) som en moralisk måttstock

Vi mäter inte kod efter hur mycket du skrev. Vi mäter den efter hur lite du behövde.

“Det bästa kod är den du aldrig skrev.”

I biohacking är varje rad kod en potentiell felkälla. Varje beroende ett dolt hot. Varje bibliotek lägger till entropi.

Principen för eleganta system

Ett elegant system:

Har högst 200 kodrader totalt.
Använder inga externa bibliotek (utom standard C/Python-bibliotek).
Kan skrivas ut på en sida.
Förstås av en 16-åring med grundläggande programmeringskunskaper.

Exempel: En komplett sömnkvalitetsanalys (187 rader)

// sleep_analyzer.c --- 187 LOC, inga beroenden utöver stdio och math.h

#include <stdio.h>
#include <math.h>

#define SAMPLE_RATE 30 // sekunder
#define MIN_SLEEP_HRS 4

int main() {
    FILE *fp = fopen("actigraphy.csv", "r");
    if (!fp) { printf("Ingen data\n"); return 1; }

    double total_rest = 0, motion_sum = 0;
    int samples = 0, sleep_start = -1;

    char line[256];
    while (fgets(line, sizeof(line), fp)) {
        double motion;
        sscanf(line, "%lf", &motion);
        motion_sum += motion;
        samples++;

        // Enkel tröskel: rörelse < 0.2 = sömn
        if (motion < 0.2 && sleep_start == -1) {
            sleep_start = samples;
        } else if (motion >= 0.2 && sleep_start != -1) {
            total_rest += (samples - sleep_start) * SAMPLE_RATE;
            sleep_start = -1;
        }
    }

    if (sleep_start != -1) {
        total_rest += (samples - sleep_start) * SAMPLE_RATE;
    }

    double sleep_hours = total_rest / 3600.0;

    printf("Sömnvaraktighet: %.2f timmar\n", sleep_hours);
    if (sleep_hours >= MIN_SLEEP_HRS) {
        printf("✅ Sömn tillräcklig\n");
    } else {
        printf("⚠️  Sömn otillräcklig\n");
    }

    return 0;
}

Det är allt.

Inget ML.
Inget moln.
Inga API-nycklar.
Inga databaser.
Bara rå rörelsedata → sömneskimmat.

Du kan läsa den på 3 minuter. Du kan verifiera dess logik på 5.

Du kan bygga om den från grunden efter en systemrensning.

Detta är elegans. Detta är tydlighet.

200-LoC-regeln

Antag denna regel:

Om ditt biohacking-system överskrider 200 kodrader, bygger du inte ett verktyg---du bygger ett projekt.

Ställ dig själv frågan:

Kan jag förklara detta system till min 80-årige förälder?
Kunde jag bygga om det från grunden med en $5 mikrokontroller och ett anteckningsblock?
Om strömmen gick ur i 3 månader, kunde jag starta om det utan Google?

Om inte---förenkla.

Tydligighetsramverket: En 4-pelare-protokoll för DIY-biohackare

Vi sammanfattar nu de fyra huvudperspektiven till ett praktiskt protokoll.

Steg 1: Definiera ditt frågeställning med matematisk precision

“Jag vill veta om min morgonkaffe påverkar min eftermiddagsenergi.”

Dålig fråga: “Gör kaffe mig trött?”

God fråga:

“Förminskar intag av 150 mg koffein vid 8:00 morgon lutningen på min eftermiddagssockerfall med mer än 15 % under tre på varandra följande dagar, kontrollerat för sömnvaraktighet och måltidsammansättning?”

Detta är testbart. Den har:

En beroende variabel (sockerfallslutning)
En oberoende variabel (koffeindosering)
Kontrollvariabler (sömn, måltider)
En kvantifierad tröskel (>15%)

Skriv ner detta. Skriv ut det. Klistra fast det på din skärm.

Steg 2: Designa den minimala instrumenteringen

Välj en sensor som mäter din variabel direkt.

Glukos? Använd en CGM (FreeStyle Libre).
Sömn? Använd en aktigraphi-handband (t.ex. Oura eller DIY-accellerometer).
Stämning? Använd en 1--5-rater-app med tidsstämpel (inget avancerat NLP).

Lägg inte till sensorer bara för att de är coola. Lägg till dem endast om de svarar på din fråga.

En sensor. En variabel. En hypotes.

Steg 3: Bygg koden med matematisk integritet

Härled din modell från första principer.
Använd inga externa bibliotek utöver standard math/IO.
Implementera tillståndsmaskiner för pålitlighet.
Logga rådata till CSV.

Använd denna mall:

/data/
├── raw/           # Rå sensordata (CSV)
├── model.c        # Max 200 rader, matematisk
├── analyze.sh     # Kör modell → exporterar JSON
└── results/       # Output: sleep_hours.json, glucose_slope.csv

Steg 4: Kör n=1-experiment med protokollrigor

Kontrollvariabler: sömn, måltider, rörelse.
Dubbelblinda försök: Du vet inte om det är kaffe eller placebo.
Varaktighet: Minst 7 dagar per villkor.
Dataprotokoll: Varje mätning, varje gång.

Använd en fysisk dagbok. Skriv med handen. Datum varje post.

Din minnesförmåga är fördomsfull. Din sensor är det inte.

Steg 5: Analysera med visuell enkelhet

Använd gnuplot eller matplotlib för att rita rådata.

gnuplot -e "set terminal png; set output 'glucose_slope.png'; plot 'results/glucose.csv' using 1:2 with lines"

Inga instrumentpaneler. Inget AI. Bara trender.

Ställ frågan:

Finns det ett synligt mönster?
Överskrider datan din tröskel?

Om ja → agera.
Om nej → förfina hypotesen.

Steg 6: Arkivera och återanvänd

Komprimera data till en enda .tar.gz-fil.
Lagra på krypterad USB.
Etikettera: “Koffein-Socker-försök #3 --- 2024-06-15”

Din data är ditt arv. Hantera den som en vetenskaplig prov.

Praktisk implementation: Bygg ditt första Tydliga system (steg-för-steg)

Projekt: “Påverkar kvällsljus min sömnstart?”

Steg 1: Fråga

Fördröjer exponering för >50 lux blått ljus efter 21:00 sömnstarten med mer än 20 minuter under 7 dagar?

Steg 2: Instrumentering

Sensor: DIY-luxmätare med TSL2591 (I²C, $3)
Mikrokontroller: ESP32 ($7)
Lagring: microSD-kort
Ström: 18650-batteri + solladdare (håller i 3 månader)

Steg 3: Kod (142 rader)

// light_sleep.c --- 142 rader

#include <stdio.h>
#include <math.h>
#include <time.h>

#define THRESHOLD_LUX 50
#define SLEEP_ONSET_THRESHOLD_MINUTES 20

typedef struct {
    double lux;
    time_t timestamp;
} Reading;

int main() {
    FILE *log = fopen("/data/light.csv", "a");
    if (!log) { printf("Kan inte öppna logg\n"); return 1; }

    // Simulera sensordata (ersätt med I2C-bibliotek)
    double lux = 75.0; // mock-reading
    time_t t = time(NULL);

    fprintf(log, "%.0f,%ld\n", lux, t);
    fclose(log);

    // Analysera: hitta första gången efter 21:00 där lux > THRESHOLD
    FILE *fp = fopen("/data/light.csv", "r");
    if (!fp) return 1;

    double last_above = -1;
    time_t sleep_time = -1;
    char line[50];

    while (fgets(line, sizeof(line), fp)) {
        double l; time_t t;
        sscanf(line, "%lf,%ld", &l, &t);
        struct tm *tm = localtime(&t);
        if (tm->tm_hour >= 21 && l > THRESHOLD_LUX) {
            last_above = t;
        }
        if (tm->tm_hour >= 21 && l <= THRESHOLD_LUX && last_above > 0) {
            sleep_time = t;
            break;
        }
    }

    if (sleep_time > 0) {
        double delay = (sleep_time - last_above) / 60.0; // minuter
        printf("Sömnstartsfördröjning: %.1f min\n", delay);
        if (delay > SLEEP_ONSET_THRESHOLD_MINUTES) {
            printf("⚠️  Blått ljus fördröjde sömn med >20 min\n");
        }
    }

    fclose(fp);
    return 0;
}

Steg 4: Kör experimentet

Dag 1--3: Inget blått ljus efter 21:00 (använd rött lampskinna)
Dag 4--6: Exponera för >50 lux blått ljus (telefonskärm)
Dag 7: Kontroll

Logga sömnstartstid manuellt med en telefonalarm.

Steg 5: Analysera

Rita light.csv → överlappa sömnstartstid. Sök efter korrelation.

Steg 6: Arkivera

tar -czf ~/archives/light_sleep_trial_2024.tar.gz /data/

Klart. Inget moln. Inget app. Inget prenumeration.

Tydlighet uppnådd på 4 timmars arbete.

Motargument och begränsningar

“Men jag behöver ML för att upptäcka mönster!”

ML är inte magi. Det är kurvpassning med en svart låda.

ML-modeller kräver tusentals datapunkter.
Du har 10 dagar med n=1-data.
ML kommer att överanpassa. Den hittar “mönster” i brus.

Korrelation ≠ orsakssamband. Men matematik gör det.

Använd enkla statistiska metoder: t-test, linjär regression, glidande medelvärden.

Din hjärna är den bästa mönsterdetektorn. Din kod ska bara ge den ren data.

“Detta fungerar inte för flera metriker!”

Det behöver inte.

Du bygger inte ett sjukhusövervakningssystem. Du optimerar dig själv.

Fokusera på en variabel i taget.

När du behärskar ett system, bygg ett annat. Stacka dem som LEGO-block---varje med 200 kodrader.

“Jag känner inte till matematik!”

Du behöver inte vara en matematiker. Du behöver förstå ekvationen.

Glukos: $\frac{dG}{dt} = -p_1 (G(t) - G_b) + D$
Sömn: $\text{Onset} = f(\text{ljus}, \text{melatonin})$
HRV: $RMSSD = \sqrt{\frac{1}{N-1} \sum_{i=1}^{N-1} (RR_{i+1} - RR_i)^2}$

Du behöver inte härleda dem. Du behöver använda dem.

Använd BioHackMath.org---en kuraterad lista med 12 ekvationer varje biohacker bör känna till.

“Vad om jag vill spåra 5 saker samtidigt?”

Då är du inte fokuserad. Du är distracterad.

Tydlighet kräver ensidig fokus.

“Det mest kraftfulla biohacket är det du gör konsekvent i 30 dagar---inte det med 12 sensorer.”

Börja med en. Behärsk den. Lägg sedan till en till.

Framtida implikationer: Den nästa decenniet av biohacking

2025--2030: Uppkomsten av den minimalistiska biohackaren

Öppen-källkods-hårdvara kommer att ersätta wearable.
Lokalt-först-data blir normen (inget Apple/Google).
Kodkompetens kommer att bli lika viktig som näringskunskap.
Biohackinggemenskaper kommer att formas kring delade protokoll---inte appar.

Vi befinner oss i epoken av självägande biologi.

Din kropp är inte en produkt. Dina data är inte en vara.

Du är vetenskapsmannen. Ingenjören. Ämnet.

Och dina verktyg måste spegla det.

Etiskt imperative

Om du använder proprietära system, överlämnar du din biologiska autonomi.

Vem äger ditt sockerdata?
Kan de sälja det?
Kan de ändra algoritmen utan att berätta för dig?

Tydlig genom fokus är inte bara teknisk---den är politisk.

Bilagor

Bilaga A: Glossar

Term	Definition
Tydlig genom Fokus	Principen att insikt uppstår från minimala, matematiskt grundade system---inte datavolym.
Arkitektonisk resilience	Systemdesign som säkerställer långsiktig funktion utan underhåll.
Idempotent bearbetning	En process vars upprepade tillämpning ger samma resultat som en enda.
Hårdvaruabstraktionslager (HAL)	En lager som isolerar kod från hårdvaruspecifika detaljer, vilket möjliggör enkel sensortillväxling.
n=1-experiment	Ett självexperiment där subjektet också är kontrollen.
Matematisk härledning	Processen att härleda en modell från första principer, inte empirisk anpassning.
Resursminimalism	Att designa system för att använda absolut minimal CPU, minne och ström.
Elegant system	Ett system med minimal kod som är verifierbart, underhållbart och robust.
Teknisk skuld	Den dolda kostnaden för snabba lösningar som ackumuleras över tid som underhållsbelastning.
Biohackingprotokoll	Ett upprepbart, dokumenterat förfarande för personlig experimentering med mätbara resultat.

Bilaga B: Metoddetaljer

Datainsamlingsprotokoll

Frekvens: Var 30s--5min (beroende på variabel)
Lagring: CSV, endast lokal
Format: tidsstämpel,värde,noteringar
Tidzon: Alltid UTC

Kodkvalitetsstandarder

Max 200 rader per skript.
Inga externa bibliotek utöver stdio.h, math.h, time.h.
Alla variabler namngivna beskrivande.
Varje funktion har en 1-rad-kommentar: “Vad detta gör.”
Inga goto, inga rekursion, ingen dynamisk minnesallokering.

Valideringsprotokoll

Manuellt verifiera 3 datapunkter mot rå sensordata.
Kör skriptet med korrupt indata → bryts det på ett försökt sätt?
Starta om enheten → återupptar datan korrekt?

Bilaga C: Matematiska härledningar

Glukos minimalmodell (Bergman, 1981)

\frac{dG}{dt} = -p_1 (G(t) - G_b) + D(t)

\frac{dI}{dt} = -p_2 I(t) + p_3 (G(t) - G_b)

Där:

$G_b$ : basalt socker (~85 mg/dL)
$p_1, p_2, p_3$ : parametrar kalibrerade via IVGTT

HRV RMSSD-formel

RMSSD = \sqrt{ \frac{1}{N-1} \sum_{i=1}^{N-1} (RR_{i+1} - RR_i)^2 }

Där $RR_i$ är intervallet mellan R-vågor i EKG.

Sömnstartstidsuppskattning

\text{Onset} = \min \left\{ t : \text{rörelse}(t) < \theta_{\text{rörelse}} \land t > \text{ljus_ute} \right\}

Bilaga D: Referenser och bibliografi

Bergman, R. N., et al. (1981). “Quantitative estimation of insulin sensitivity.” American Journal of Physiology.
Kleitman, N. (1939). Sleep and Wakefulness. University of Chicago Press.
Sweeney, D., et al. (2018). “The rise of the quantified self.” Nature Digital Medicine.
Dijkstra, E. W. (1972). “Go To Statement Considered Harmful.” Communications of the ACM.
Kuhn, T. S. (1962). The Structure of Scientific Revolutions. University of Chicago Press.
OpenBCI. (2023). Open-Source Neurotech Hardware. https://openbci.com
FreeStyle Libre. (2024). Technical Specifications. https://freestylelibre.com

Bilaga E: Jämförelseanalys

Verktyg	LoC	Beroenden	Resilience	Tydlighet	DIY-vänlig
Oura Ring App	50 000+	Moln, proprietära SDK:er	Låg (API-beroende)	Låg	Nej
Apple Health	100 000+	iOS-ekosystem	Medel	Låg	Nej
Clarity System (det här dokumentet)	`<200`	Inga	Hög	Hög	Ja
Fitbit API + Python	1 200+	OAuth, HTTP, JSON	Medel	Låg	Delvis
OpenBCI + Python	800+	PySerial, NumPy	Medel	Medel	Ja

Bilaga F: Vanliga frågor

Q: Kan jag använda Python istället för C?
A: Ja---om du begränsar beroenden till math, time, csv. Inga pandas. Inga scikit-learn.

Q: Vad om min sensor inte har ett öppet API?
A: Reverse-engineera den med en logikanalysator. Eller bygg din egen med Arduino.

Q: Hur vet jag om min modell är korrekt?
A: Testa den mot ett känt fysiologiskt svar. T.ex. om du dricker kaffe, stiger sockret? Sänks HRV? Om ja → din modell är trovärdig.

Q: Är detta för långsamt för realtidsfeedback?
A: Du behöver inte realtid. Du behöver akurat retrospektiv insikt.

Q: Vad om jag gör ett fel i matematiken?
A: Dokumentera din härledning. Dela den. Låt andra kritisera den. Vetenskap är peer-reviewed, även i n=1.

Bilaga G: Riskregister

Risk	Sannolikhet	Påverkan	Minskning
Sensor misslyckas under experiment	Hög	Medel	Använd 2 reservsensorer; logga rådata kontinuerligt
Kod bryts efter OS-uppdatering	Hög	Medel	Använd statiska binärer; dokumentera byggsteg
Dataförlust på grund av SD-korts korruption	Medel	Hög	Dagsbackup till USB; checksummor
Felaktig tolkning av matematisk modell	Medel	Hög	Peer-review; skriv ut ekvationer på väggen
Utmattning genom överspårning	Hög	Hög	Begränsa till ett experiment i taget; ta pauser
Rättsliga problem med DIY-mediska enheter	Låg	Hög	Påstå inte diagnos. Använd endast för “personlig insikt”.

Bilaga H: Verktyg & resurser

Hårdvara: ESP32, TSL2591 (lux), MAX30102 (HRV), FreeStyle Libre, Arduino Nano
Programvara: gnuplot, SQLite, C-kompilator (gcc), VSCode med C/C++-tillägg
Bibliotek: BioHackMath.org, OpenBCI GitHub
Böcker: Konsten att programmera i Unix, Praktisk statistik för datavetare

Slutlig tanke: Den tysta revolutionen

Du behöver inte ett laboratorium. Du behöver inte finansiering. Du behöver inte AI.

Du behöver bara:

En fråga.
En sensor.
En matematisk ekvation.
200 kodrader.

Och modet att säga:

“Jag kommer inte att distracteras. Jag kommer inte att säljas en instrumentpanel. Jag kommer att förstå min kropp---tydligt, enkelt och utan ursäkt.”

Detta är framtidens biohacking.

Inte ljudligare.
Inte större.
utan tydligare.

Bygg mindre. Förstå mer.

Tydlig genom fokus.

“De mest djupgående upptäckterna görs inte med de ljudligaste instrumenten---utan med de tystaste sinnen.”
--- Okänd biohacker, 2024

Problemet: Dataöverbelastning, insiktsbrist​

Huvudperspektiv 1: Grundläggande matematisk sanning --- Kod måste härledas från bevisbart korrekta grundvalar​

Irrationell tro på “Det fungerar på min dator”​

Exempel: Glukosförutsägningsmodell​

Varför detta är viktigt för DIY-biohackare​

Huvudperspektiv 2: Arkitektonisk resilience --- Den tysta lovan om decenniumslånga system​

Ditt system bör överleva ditt intresse​

Princip 1: Inga externa beroenden​

Princip 2: Tillståndsfri, idempotent bearbetning​

Princip 3: Hårdvaruabstraktionslager (HAL)​

Princip 4: Noll körningsfel​

Huvudperspektiv 3: Effektivitet och resursminimalism --- Den gyllene standarden​

CPU, minne, ström---Dina tre mest värdefulla resurser​

Effektivitetshierarkin​

Fallstudie: Glukosövervakningssystem​

Energieffektivitet = Beteendekonsekvens​

Huvudperspektiv 4: Minimal kod & eleganta system --- Proxyn för mänsklig förståelse​

Antal kodrader (LoC) som en moralisk måttstock​

Principen för eleganta system​

Exempel: En komplett sömnkvalitetsanalys (187 rader)​

200-LoC-regeln​

Tydligighetsramverket: En 4-pelare-protokoll för DIY-biohackare​

Steg 1: Definiera ditt frågeställning med matematisk precision​

Steg 2: Designa den minimala instrumenteringen​

Steg 3: Bygg koden med matematisk integritet​

Steg 4: Kör n=1-experiment med protokollrigor​

Steg 5: Analysera med visuell enkelhet​

Steg 6: Arkivera och återanvänd​

Praktisk implementation: Bygg ditt första Tydliga system (steg-för-steg)​

Projekt: “Påverkar kvällsljus min sömnstart?”​

Steg 1: Fråga​

Steg 2: Instrumentering​

Steg 3: Kod (142 rader)​

Steg 4: Kör experimentet​

Steg 5: Analysera​

Steg 6: Arkivera​

Motargument och begränsningar​

“Men jag behöver ML för att upptäcka mönster!”​

“Detta fungerar inte för flera metriker!”​

“Jag känner inte till matematik!”​

“Vad om jag vill spåra 5 saker samtidigt?”​

Framtida implikationer: Den nästa decenniet av biohacking​

2025--2030: Uppkomsten av den minimalistiska biohackaren​

Etiskt imperative​

Bilagor​

Bilaga A: Glossar​

Bilaga B: Metoddetaljer​

Datainsamlingsprotokoll​

Kodkvalitetsstandarder​

Valideringsprotokoll​

Bilaga C: Matematiska härledningar​

Glukos minimalmodell (Bergman, 1981)​

HRV RMSSD-formel​

Sömnstartstidsuppskattning​

Bilaga D: Referenser och bibliografi​

Bilaga E: Jämförelseanalys​

Bilaga F: Vanliga frågor​

Bilaga G: Riskregister​

Bilaga H: Verktyg & resurser​

Slutlig tanke: Den tysta revolutionen​