Commitments that survive a timezone crossing.
Distributed teams don't fail from a lack of communication tools. They fail because the agreements made between people never become records. This is the specific problem StandIn was built for — and this page explains exactly how.
The real coordination failure isn't communication.
Your distributed team has Slack, Jira, Notion, Linear, GitHub. They're full of communication. What they don't have is a layer that makes commitments binding. Decisions get made in Zoom calls and live in nobody's notes. Approvals happen in DMs that don't survive the next sprint. Scope changes get agreed verbally — and reversed the moment someone's offline and can't defend them. This isn't a tooling problem. It's a structural gap: no mechanism exists to make a commitment survive a timezone crossing.
A declaration is not a message.
Every time an engineer publishes a wrap, they're making a deliberate choice about what to put on the record.
A Slack message shares information. It can be missed, scrolled past, misread, or never found again. A declaration creates a record. When an engineer writes a wrap — what shipped, what's blocked, who owns the next action, when they're back — they're not sending a note. They're making a structured commitment to the record. It's closer to a git commit than a Slack message — selective, intentional, and permanent. You choose what goes in. That record is typed, validated, timestamped, and queryable. StandIn's AI can answer from it. An auditor can cite it. A successor can act on it. The commitment survives the person going offline.
The system that refuses is the system you can trust.
Most AI tools are optimized to answer. StandIn is optimized to be right. The difference matters: when an AI fills a gap with inference, it produces a confident answer that might be wrong. In distributed engineering, a confident wrong answer about who can approve a deployment costs hours. StandIn refuses any question it can't answer from declared state. That silence is information. It tells you the state hasn't been declared — and you know what to do about that.
"Silence is not a failure mode. Confident wrong answers are."
This is not a standup bot.
Standup bots ask what you did yesterday. StandIn records what you declared — and makes that declaration queryable, auditable, and binding. Standup bots produce output that gets read once and forgotten. StandIn produces records that survive. The outputs of a standup bot are messages. The outputs of StandIn are commitments. If you're comparing StandIn to standup bots, you're comparing the wrong things.
Representatives are the queryable surface of declared state.
A Representative is what makes declared state useful. Without it, a wrap is a document someone has to find and read. With a Representative, a wrap becomes a surface anyone can ask a question to — and get a sourced answer from.
The Protocol specifies how Representatives are instantiated (from published wraps), how they expire (when a new wrap replaces the old one), and what they refuse to answer (anything that would require guessing beyond the published record). A Representative is not an assistant. It is the queryable form of a commitment.
Three types exist. A Personal Representative speaks from one person's published wrap. A Team Representative rolls up wraps from an entire team. A Project Representative spans teams and timelines for a specific initiative. Each inherits the same refusal rules. Each cites its source.
How Representatives work