Workflow 023: The Symptom And Meal Log

Your doctor asks what you ate before it started, and when it began, and how bad it was.

Nobody remembers.

This workflow is a log. You record what you ate and how you felt, with a time and a severity number. It builds a history, spots patterns across weeks you'd never see day to day, and reminds you of the thresholds your doctor gave you.

It doesn't diagnose. It keeps records, so the person who does diagnose has something real to work from.

What this replaces

Trying to reconstruct three weeks of meals in a five minute appointment.

Anyone managing a condition with a food component, or watching for symptoms after a diagnosis, gets asked the same questions. What did you eat. When did the pain start. How bad, out of ten. Has it happened before. Was it worse this time.

Memory is genuinely bad at this. Not a little bad. You'll swear something happened last Tuesday and be off by two weeks.

Blueprint

Two logs, one place.

Trigger: manual, whenever you eat something worth recording or feel something worth noting. Inputs: meals, symptoms, severity, time of day, medications, and anything your doctor told you to watch for. Output: a searchable history, plus answers when you ask.

What goes in each log:

• The meal log. What you ate, when, and roughly what was in it. Also works in the other direction: paste a menu and ask what fits your restrictions.
• The symptom log. What you felt, when, where, how bad on a scale, and what you'd eaten beforehand. Include anything else worth noting, like medication side effects.

Organize

What has to exist before it's useful:

• A database with a place for meals and a place for symptoms
• Your restrictions, written plainly. Foods you can't eat, foods you're avoiding for now
• Any lab results or written instructions from your doctor
• The escalation thresholds your doctor gave you, in their words
• Your medications, so side effects can be flagged rather than mistaken for something new

That escalation line matters more than anything else in this workflow. It comes from a doctor, not from an AI, and not from you guessing.

Where to keep it

Any of these work. Pick the one you'll actually open on a bad day.

Notion. What I use. Two linked databases, easy to search, easy to filter by date before an appointment. Good if you already live in it.

Google Sheets. Simpler and faster to set up. One tab for meals, one for symptoms, columns for date, time, entry, severity. Fine if you don't want another tool.

Apple Notes or Obsidian. Both stay on your device by default. Obsidian keeps plain text files in a folder you control, with nothing on anyone's server unless you turn on syncing. This is the most private option.

A paper notebook plus photos. Not a joke. If you'll write in a notebook but you won't open an app, use the notebook and photograph the pages when you want the AI to read them.

Keeping it private

This log holds your health information. Worth a few minutes of setup:

• Use a separate page or file, not your work workspace. If your Notion is connected to a team, a client, or an assistant, this belongs somewhere else entirely. Ideally a different account.
• Check who has access. Anything shared with a team, an EA, or a collaborator is the wrong home for this. Same for a Google Sheet inside a company workspace, since an admin can usually see it.
• Turn off sharing links. A "anyone with the link can view" setting on a health log is a bad afternoon waiting to happen.
• Be deliberate about what the AI can reach. If your assistant has access to the same AI workspace, this log shouldn't be in it. Use a separate project or a separate account.
• Check the retention settings on whichever AI you use, and whether that account is a personal or a business one. Business and team plans have different rules about what's stored and who can see it.
• Leave out what you don't need. A severity number and a food is enough to spot a pattern. Full names of doctors, clinic details, and insurance information don't need to be in there.
• Local storage is the strongest option. If privacy matters more to you than convenience, keep the log in plain text files on your own device and paste in only what you want read.

The general principle: this is the one workflow where the least connected version is the better version. Everything else in my stack gets better the more it's wired into. This one doesn't.

Systematize

You are my health log. You keep two records for me and answer questions
about them. You are not a doctor and you do not diagnose.

My context:
- What I'm managing: [CONDITION OR WHAT YOU'RE WATCHING FOR]
- Foods I can't eat: [LIST]
- Foods I'm avoiding for now: [LIST]
- Medications I'm taking: [LIST]
- What my doctor told me to watch for: [IN THEIR WORDS]
- When my doctor said to seek help: [THE EXACT THRESHOLD, e.g. pain above
  a certain level, pain that radiates, symptoms lasting beyond X hours]

THE MEAL LOG
When I tell you what I ate, record it with the time and what was in it.
When I paste a menu or a list of options and ask, tell me what fits my
restrictions and what to avoid. Say when you're unsure about an
ingredient rather than guessing.

THE SYMPTOM LOG
When I report a symptom, record: what it is, where, severity out of ten,
the time, what I ate beforehand, and anything else I mention.

Then check it against the threshold above. If I've reached what my doctor
said to watch for, tell me plainly, and tell me what I said I'd do about it.

ANSWERING QUESTIONS
When I ask about patterns, search both logs and tell me what you actually
find, with dates. If the data is thin, say so rather than inferring a
pattern from two entries.

You can explain medical terminology from my lab results in plain language,
so I know what to ask about. You never interpret what a result means for
my health. That's my doctor's job.

NEVER
- Diagnose, or suggest what a symptom might mean
- Tell me a symptom is nothing to worry about
- Change or reinterpret the thresholds my doctor gave me
- Recommend stopping, starting, or changing a medication

How to set it up

1. Pick where the log lives, and check the privacy settings before you put anything in it.
2. Build the two logs. Keep them simple, since anything fiddly won't get used on a bad day.
3. Write in your restrictions and your medications.
4. Write in what your doctor told you, using their words, including the point at which they said to get help.
5. Log for a couple of weeks before expecting anything useful. Patterns need data.
6. Bring the log to your next appointment.

What does this actually look like day to day?

Mostly two sentences. "Ate the chicken thing at the place near the office around 1pm." Or "Pain in the same spot, about a four, started an hour after lunch."

And then the other direction, which is the part I'd have used most: paste a delivery menu, ask what's safe, order that.

Assign

The log records, searches, and reminds.

Every decision belongs to a person, and the important ones belong to a doctor.

This is the workflow where the human line matters most, so it's worth being blunt about where it sits.

An AI can tell you what you ate on the fourteenth. It can tell you that six of your last ten bad days followed a similar meal. It can remind you that your doctor said a certain severity means going in.

It cannot tell you what's wrong with you. It cannot tell you that a symptom is fine. And the threshold for getting help has to come from a clinician who examined you, written down in advance, not generated in the moment by something trying to be reassuring.

Set up badly, this workflow becomes a way to talk yourself out of going to the doctor. Set up properly, it does the opposite: it holds you to a decision you already made with a professional, on a day when you feel bad enough to want to renegotiate it.

Rule of thumb from this build: let AI keep the record, keep every medical decision with a doctor.

Integrate

This one sits apart from my business stack on purpose, but it works the same way:

• Both logs live in one database, so the history is searchable
• Restrictions are written once and applied every time I ask about food
• Thresholds are written once, in a doctor's words, and checked on every entry
• The record goes to appointments, so the conversation starts from data rather than recall

It's the least impressive workflow I run and one of the most useful, which is usually a sign the problem was real.

If you're managing something ongoing, the version of this that helps is the one you'll actually update on a bad day. Build it small.

Tomorrow: the agent that researches a topic across Reddit, Twitter, and Threads so I can keep up with something that's moving fast.