Activities
The unit everything you track in ASIOS is built out of, and how a conversation drives it.
On this page
Every piece of tracked work in ASIOS — big or small — is an activity. An activity is identified by one stable id, assigned the moment an idea is captured, and that same id is reused, unchanged, by everything that grows out of it. There's no separate ledger mapping ids to work elsewhere; the activity is the master record.
From idea to activity
You don't create an activity by filling out a form. You drop an idea — a sentence, a task, a question — into a capture surface, and the system:
- assigns it a stable id,
- spins up both an activity (the tracked-work record) and a conversation (the record of what was said about it), sharing that one id, and
- immediately starts working it, rather than leaving it to sit until someone picks it up.
Conversations happen inside activities
A conversation is the ongoing back-and-forth about an activity — your instructions, the system's response, any open questions — and it lives inside that activity's own folder, not in some separate inbox. Each turn is worked in place: you write what you want at the top of the conversation file, the system acts on it and writes its answer back into that same top block, and the previous turn is folded, unedited, into the activity's permanent history underneath. Nothing about a turn is thrown away — it just moves from "current" to "history" as the next turn begins.
A Conversation is the whole back-and-forth; a Message is one turn in it. When people talk about "dispatching" something, they mean acting on the current top block of a Message.
Status: a small, honest set
An activity's status is always one of three values:
- Active — live work someone is actually driving right now.
- Hold — recently idle, still open, but out of the active view.
- Closed — done, or idle long enough that it's no longer worth tracking as open work. Closing doesn't delete anything; the activity's folder and history stay exactly where they are.
Status changes by hand, on purpose — nothing quietly ages from Active to Hold to Closed on a timer. The one exception is reopening: dispatching a Hold or Closed activity again always brings it back to Active first, so picking an old conversation back up is never a dead end.
Why one id, not several
Because the activity id is the master id for everything that grows out of it — its conversation, and any plan or project it later escalates into — nothing needs a separate cross-reference table to find "the work behind this conversation" or "the conversation behind this task." The id you started with is the id you'll still be using at the end.