SevenGrid as a data-entry instrument for research

Instrument sheet version: 1.2, 2026-09-12. Describes: SevenGrid for Android, app version 1.5.0. Every statement below is taken from the app's source and configuration on that date; nothing here is a study result.

Purpose of this sheet. Research groups who consider letting participants log a few daily behaviours need to know exactly what the tool records, where it stores it, how it exports it, and what it does not do. This sheet answers those questions the way a methods section or an ethics application would ask them. It is not marketing material and carries no usage or sales figures.

1. What SevenGrid is, in one paragraph

SevenGrid is an Android app for manual daily behaviour logging. A person defines a small number of behaviours ("habits"), and each day taps a cell to record whether, and how many times, the behaviour happened. Optional per-day notes, per-day measurements (amount, duration), and a short weekly reflection can be added. All data are stored in a local SQLite database on the device. There is no SevenGrid account, no SevenGrid server, no synchronisation, no advertising, and no usage analytics. Data leave the device only when the user exports them (CSV or JSON) or arms an automatic daily backup into a folder the user chooses. The app has not been validated as a research instrument and makes no clinical or therapeutic claims.

2. Claims this sheet does not make

• Not "validated", "scientifically validated", or a "validated habit measure". A tap records self-reported behaviour, not habit strength or automaticity.
• Not "improves habit formation", "helps habits stick", or any adherence claim.
• Not "prevents backfire" or "healthier than streak tracking". The app simply computes no streak metric and marks no day as "missed" or "late".
• Not "privacy-preserving" as a seal, "ethics-approved", or "GDPR-certified". Section 7 states the concrete data flows; a study protocol decides whether they suffice.
• Not an N-of-1 or single-case platform. The app randomises nothing, enforces no phases, and analyses nothing. It can supply one data source (manually entered daily values as CSV) to such a design.
• Not "digital phenotyping". No sensors, no passive data, no location.
• Not "clinically effective", not a medical device, no health condition addressed.
• No iOS availability or date is stated. This sheet covers Android only.

3. Platform, versions, requirements

4. What is recorded

Seven SQLite tables. Field names below are the database column names; the CSV column names in section 6 map onto them.

4.1 Habit (behaviour definition), one row per habit

4.2 Check (the daily entry), one row per habit and calendar day

4.3 Day note: habit_id, date, note (free text), created_at

4.4 Day measurement: habit_id, date, amount (decimal), duration_seconds (integer), created_at. Numbers are stored machine-readably, locale-independent.

4.5 Day skip (rest day): habit_id, date, created_at. A deliberate "not today": the day is treated as neither done nor missed.

4.6 Weekly review, one row per ISO week

week_start_date (the ISO Monday, regardless of the user's visual week start), mood (optional, integer 1 to 5), went_well, didnt_work, next_week_focus (free text), created_at, updated_at.

4.7 Settings: key-value pairs

Preferences (theme, language, reminder and quiet-hours configuration, week start, widget display options, backup folder) plus a few one-shot flags and cadence markers the app uses to avoid repeating itself (for example whether a hint was already shown, the last date a home-screen card appeared, the last time the weekly review was opened, the last automatic backup). No per-session log, no history of app opens or screens viewed. Only an allow-listed subset of these keys travels in the export (section 6); device-bound markers stay on the phone.

Not recorded: a log of app opens or screen views, tap latency, location, sensor data, device identifiers, names, e-mail addresses.

5. Day and week semantics

• A "day" is the device's local calendar date at the moment of the tap, serialised with local-time accessors (never converted through UTC). No time zone is stored with a row.
• The current day rolls over at local midnight. An entry made at 00:30 belongs to the new date unless the person deliberately taps the previous day's cell (which is allowed; see created_at in 4.2).
• Travel and DST: existing rows keep their date strings; nothing is re-labelled retroactively. A person who crosses time zones logs against the new local date. A study spanning time zones should treat date as "the participant's local day" and not compare it to server time.
• Manually changing the system clock changes what "today" is. The app does not detect this.
• Weeks: the visual week may start on Monday, Sunday, or Saturday (user setting); the weekly review key is always the ISO Monday.
• Reminders are local notifications and are never a data source.

6. Export formats

All exports are produced on the device from the full tables. No tier limit applies to any export: the free tier's four-week window (section 9) limits what the grid displays, not what is stored or exported.

6.1 Manual export (Settings → Data)

Per strand as CSV, plus a complete JSON backup. Conventions: UTF-8 with byte-order mark, RFC 4180 quoting, ISO dates YYYY-MM-DD, timestamps ISO 8601 in UTC (…Z), booleans as 1/0, decimal point ., deterministic row order (habit creation order, then date ascending). Columns are only ever appended; older files remain importable. Exact headers, version 1.5.0:

checks:        habit_id,habit_name,habit_color,habit_goal,habit_icon,habit_daily_target,
               habit_partial_streak,date,checked,count,created_at,habit_identity_statement,
               habit_created_at,habit_archived_at,habit_reminder_time,habit_measure_unit,
               habit_track_duration,habit_goal_direction,habit_cue,habit_skip_weekdays,
               habit_allow_overshoot,habit_show_count,habit_reminder_times_by_weekday
reviews:       week_start_date,mood,went_well,didnt_work,next_week_focus,created_at,updated_at
notes:         habit_id,date,note,created_at
measurements:  habit_id,date,amount,duration_seconds,created_at
skips:         habit_id,date,created_at
settings:      key,value

The settings strand contains only the allow-listed preference keys, never device-bound markers.

Notes on checks: checked is 1 on every logged row and 0 only on the placeholder row of a habit without entries. Every row repeats the habit's configuration (habit_* columns) so the file is self-describing and row-order safe. A habit with no entries yet is written as one row with checked=0 so it is not silently dropped. habit_goal is the weekly goal.

6.2 Automatic daily backup (optional, off by default)

The person picks a folder through the system file picker (device storage, SD card, or a folder that a third-party app syncs). Once per day on app launch or resume, the app writes the six strands as sevengrid-<YYYY-MM-DD>-<strand>.csv into that folder and keeps the newest seven days of its own files. It never deletes files it did not create. The folder survives uninstalling the app. This is the recommended hand-over path in a study: the participant chooses when, and whether, to pass a file to the research team; the app itself never transmits anything.

6.3 Import

The app re-imports its own CSV and JSON formats (merge, duplicates skipped), so a participant can move to a new phone without any cloud.

7. Where data go, component by component

8. Deletion

• In-app: Settings → Data → delete everything. Deletes the SQLite file (all seven tables and every setting) and restarts at onboarding. Backup files in the person's chosen folder are deliberately left alone (they are the person's own files); the Pro entitlement lives with the Google account and is untouched.
• Uninstall: removes the database and app-private files. Files in the chosen backup folder remain until the person deletes them.
• Crash reports already sent cannot be recalled from the app; retention is governed by the crash-reporting provider's settings.

9. Tiers and what a study participant can use for free

A study needing at most three behaviours per participant runs entirely on the free tier; no code, coupon, or account is needed. The four-week display window does not affect the data or the export.

10. Known limitations for research use

• Manual self-report, one value per behaviour per day; no prompts beyond optional fixed-time reminders; no compliance monitoring; no server.
• Un-checking a day deletes the row: there is no audit trail of changes.
• Missing row = "not logged"; the app cannot distinguish "did not happen" from "forgot to log". A study can add an explicit "did not happen" habit or use the rest-day skip for planned absences.
• Android only. Mixed-device cohorts need a second instrument (the printable weekly sheet exists but is not a comparable data source).
• Closed source; behaviour is documented here and in the export headers, not inspectable by the research team.
• Single-user device; the app has no participant id. Studies assign their own id when they receive the files.

11. Contact and versioning

Questions about this sheet, or requests for a field to be documented in more detail: stefan [at] sevengrid [dot] app. The sheet is versioned with the app; a new app version with schema or export changes gets a new sheet version, and the "Columns are only ever appended" rule in section 6 is the compatibility promise.

Change log

• 1.2 (2026-09-12): checked defined, "at most" count semantics, UTC note on created_at, future days cannot be logged, mood range, rest-day wording.
• 1.1 (2026-09-12): permission list taken from the built package instead of the config (adds the install-time and library-declared permissions), purchase-status check happens at every launch, settings keys described honestly, reminders row.
• 1.0 (2026-09-12): first version, describes app 1.5.0.