Intent Loop
A local research system for connecting phone-use context, sessions, interruptions, and outcomes, with a reproducible profile-model baseline and a separate simulated event pipeline.
What it is
The research question is when phone use becomes unwanted and which interruption is useful. Answering it needs consented longitudinal context and outcomes, not only a profile label.
The current console and simulator make the data path inspectable. They demonstrate how a future event stream could be recorded and analyzed without claiming access to real Android usage telemetry.
The loop it has to make believable
- 01
Replay simulated phone-use events and inspect the derived sessions, fixed risk heuristic, and intervention outcomes in a debugging console.
- 02
Train and compare profile baselines, then inspect out-of-fold predictions, calibration-related metrics, and saved run provenance.
How it’s built
The offline experiment uses baseline comparisons, fold-local preprocessing, data-quality checks, and immutable artifacts. Its saved out-of-fold predictions make aggregate evaluation reviewable.
The runtime prototype uses a Go metadata API and PostgreSQL history. Session derivation is anchored at session start; future and overlapping sessions are excluded. The risk endpoint reports simulated-only behavior and uses a fixed heuristic rather than the Kaggle profile model.
Architecture
- Profile experiment
- Dummy, logistic, ExtraTrees, and histogram gradient-boosting comparisons with fold-local preprocessing
- Artifacts
- Immutable run directories hold configuration, metrics, feature definitions, model, manifest, and out-of-fold predictions
- Events
- Go API and PostgreSQL store metadata history with stable event identities and duplicate-safe retries
- Sessions
- Features use completed history available at session start and exclude future or overlapping sessions
- Feedback
- Intervention outcomes and dataset snapshots provide a basis for later longitudinal analysis
What has to hold up
- Fit preprocessing inside each fold and audit synthetic structure instead of treating a strong aggregate score as product validation.
- Prevent session features from seeing future or overlapping sessions; keep the trained profile artifact out of the simulated session-risk endpoint.
Research limits
The bootstrap data is synthetic and structurally easy to predict. Its offline score does not validate a diagnosis, a real-time session-risk model, or the effectiveness of an intervention.
There is no Android telemetry integration, learned intervention policy, clinical validation, production authentication, or public deployment. Session-day boundaries also need an explicit user-timezone contract before real use.
Proof
VerifyRepository, checks, stack, status
- 01
Read the data audit and product thesis before interpreting the profile metrics.
- 02
Inspect the saved profile-s6e8-v002 configuration, manifest, metrics, and out-of-fold predictions.
- 03
Follow make test, make up, make simulate, and make smoke in the local README to review the event path.
- 04
Compare the session feature contract with test_features.py and inspect the risk endpoint's simulated-only boundary.
- Role
- Data audit, baseline comparison, reproducible artifacts, event contracts, and session derivation
- Scope
- Offline profile-model research, metadata simulation, event API, and debugging console
- Proof
- docs/data-audit.md and docs/features.md; experiments/profile-s6e8-v002/; tests/test_features.py; services/api/internal/domain/domain_test.go
- Stack
- Python, scikit-learn, Go, PostgreSQL, Parquet, Docker Compose
- Profile evaluation
- Threefold out-of-fold
- Event history
- Append-only, retry-safe
- Session features
- Point-in-time derivation
- Risk endpoint
- Simulated heuristic