Rolodex

Rolodex loops

How to feed Rolodex conversations and read back who is owed a move and who could be asked.

Rolodex

Rolodex keeps a log of any conversation that builds context on a relationship,
with the source beside every line, and answers two questions from it: who do I
owe, and who could I ask.

This file is the only copy of these instructions. The rolodex.guide tool serves
it by topic, the MCP prompts and resources export it, and rolodex.rails.so/docs
renders it. If you find the same rule written somewhere else, that copy is wrong.

start: what to do first

1. Read this topic, then sync, before your first call.
2. Fetch the conversations you can reach. Send them with rolodex.sync.
3. Ask rolodex.followups.due what the person owes, or rolodex.who.to.ask who

could help with a goal they name.

1. Offer the rolodex.today link. The page opens on a phone with no login.

25 sync calls are free for the life of an installation. Reads, History,
export and revoke are never charged.

sync: what to send

Send any conversation that builds context on a relationship, not only mail:
message threads, meeting notes, calls, and the attendees of today's and
tomorrow's calendar events. A Granola note is a meeting note; send it.

Send whole conversations. Never a snippet. A thread cut short can show the wrong
person owing the next move, because the messages you left out are exactly the
ones that would change the answer.

With every thread:

• message_count_declared (required; the older spelling declared_message_count

also works): how many messages the thread actually has. Rolodex checks it
against the message ids you send. Set complete: true only when you sent them
all. If the thread is short, or complete is missing, it still ingests, and it
is recorded as partial and never opens a loop on its own.

• view: personal or commercial, chosen by the owner for each thread. Never

infer it from the channel, content, profession or context, and never label a
person or fact commercial on your own; ask the owner when the view is unknown.
The field is optional in sync: an omitted view is stored as personal for
privacy, which is not the owner's choice and never permission to show a row
commercially. A commercial answer never ranks a personal contact, and a
personal occasion or commitment never counts toward a commercial score.

• One line of claim per message. Never the body. Rolodex stores claims and

ids; the mailbox stays yours.

• message_ref on every line you actually read. A line you did not read in a

mailbox — something the person told you on a call, or something you worked out
yourself — sends evidence_class of user_stated or inferred and no
message_ref at all. That is allowed and is never refused. A loop built only
from inferred lines is kept, shown with "no source", and never ranked.

• occasions for a meeting or call the host actually reported. Each needs

occasion_ref, format (one_on_one, small_group, group, async, solo),
medium, initiator and occurred_at; add duration_minutes, where_met,
why_met and citations when you have them. Where and why two people met is
what keeps an event contact from becoming a useless name six months later. An
invitation or an organizer field alone is not evidence that someone attended,
and sync records no separate attendance flag or notes source.

• commitments for promises. Each needs party (me or them), text and

the source_sentence that proves it, quoted as written (Rolodex keeps up to
500 characters, with runs of whitespace collapsed); add due_at only if a
date was named, and citations when you have them.

With every sync call, for each channel you read: the window, the count, any
error, and a status. The status is one of ok (you read it and sent what you
found), empty (you read it and there was genuinely nothing), partial (you
sent less than you found), stale (your last good read is older than the
channel's freshness window), unavailable (you could not reach it at all) or
error (you reached it and it failed). Anything but ok and empty must say
why, in words the person can read.

Send the coverage row even when a channel found nothing. Without it an outage
reads as a quiet week, and that is the one mistake this product cannot make.

At most 100 source items or 256 KiB per call. A source item is a thread plus
each of its messages, occasions and commitments, so a hundred threads of one
message and one thread of a hundred messages are the same size. Past either
limit the call refuses with batch_too_large and you page the rest.

Pass an idempotency_key, and a different one per batch. A key Rolodex has
already answered returns that first answer and ingests nothing, whatever you send
with it, so reusing a key silently drops the batch you thought you sent.

classify: what you are deciding

An introduction is a message where a third party connects two people, or one
person asks permission to make that connection, or a referral arrives naming who
sent it. Kinds: intro, opt_in_request, referral_inbound.

One loop per introduction across channels. The same intro in Gmail and iMessage
is one loop.

For each one, say: the kind; the owner of the next move, one of me, them,
introducer, unclear; the obligation, one of acknowledgment, reply,
scheduling, answer, follow_up; the message id that proves it; one line of
rationale. Recompute ownership on every newer message.

A loop cites its source: a message id, or the person's own statement recorded as
user_stated with its date. A loop with neither is stored as inferred, shown
dashed with "no source", and never ranked. Nothing is refused for lack of a
citation.

For every thread that is not a loop, send one exclusion_reason from this
fixed set, so "nothing owed" can be audited: cold_outreach, recruiter_only,
automation_or_business, fyi, replied, waiting_on_them, social_chatter,
mention_only, public_figure, no_intro_event.

morning: the daily read

Call rolodex.followups.due. Read the owed loops and commitments aloud, each
with its citation. Offer the rolodex.today link.

Then suggest one block for the morning's replies, and **fold it into the block
the person already keeps for daily work** — their existing Todo or timeboxing
block. Update that block in place, and take the line out when nothing is owed.
Never create a separate system-named calendar event. Rolodex does not write
calendars on a third-party host; you do, with your own calendar tool, when the
person asks.

You draft and you send. That is your job, not Rolodex's. When the person asks you
to reply to someone, write it and send it with your own tools; it comes back as
evidence on the next sync.

After a page: poll exercise.status or use link_wait, then read the change
back with rolodex.person.lookup.

refusals: what sync can return

• thread_incomplete — a snippet, not a thread.
• batch_too_large — over 100 source items or 256 KiB. Page it.
• free_limit_reached — this installation's 25 free sync calls are used.

Rolodex is free, so there is nothing to buy and no link; show the sentence
and stop syncing. Lookups, notes, follow-ups, corrections and closing loops
keep working.

• sign_in_required — send the person to the connect URL in the message.

never

• Never merge two people on a name match. A name-only match becomes a proposal.
• Never treat a proposal as a fact. Pencil is pencil until the person confirms.
• Never paraphrase a citation. The stored sentence is the one that was written.
• Never create a person from a mention. A mention is not an interaction.
• Never surface spam, cold outreach, automated senders, or public figures who

never wrote to the person.

• Never send Rolodex a message body where a claim belongs.

Example prompts

What a person actually says, and what it asks of you. The first proof is measured
on introductions; the product is not limited to them.

• "Who do I owe a follow-up?" — sync, then rolodex.followups.due.
• "Who could I ask about hiring in Lisbon?" — rolodex.who.to.ask with that goal.
• "How warm are Priya and I, and why do you think so?" — rolodex.person.lookup,

and read the signals back, not just the band.

• "What did Dan and I build together?" — rolodex.person.lookup; the occasions

and the confirmed facts, each with its citation.

• "Remember that Sam prefers a call." — rolodex.note.add. No import, no setup.
• "No, she is VP Engineering now." — rolodex.correct. Their answer holds.
• "Show me my network for the fundraise." — rolodex.who.to.ask, commercial view.
• "That's the same Marcus." — look both up with rolodex.person.lookup, then

rolodex.correct action merge naming both keys. The owner named them, so this
is not a name match. unmerge with the returned merge_key undoes it.

• "Her LinkedIn is linkedin.com/in/…" — rolodex.correct action

attach_identity. identity_collision means the address is already someone
else's: ask whether they are one person, then merge.