The decision log
The Decision Log records four things about every action Connect or a person takes on an outbound: what was decided, by what or by whom, under which rule, and what actually happened. Refusals are written in the same shape as actions. It is scoped to one workspace like every other record, and it is the screen that answers questions nobody thought to ask at the time.
The four things in every entry#
- What was decided
- The action itself — a reply released, a call placed, an item declined, a send refused.
- By what
- A person, named, or Connect acting under a rule, or the Connect Assistant acting on a request. These are not collapsed into one actor.
- Under which rule
- The autonomy setting or the gate in force at that moment. Not the setting as it stands today — the one that actually decided.
- What happened
- The outcome, including the provider's own acknowledgement where one exists. Until that acknowledgement arrives a send is *uncertain* rather than *sent*, and the log says so.
Refusals are first-class entries#
A refusal is a decision, so it is recorded like one. That single choice is what makes the log usable for the question people actually bring to it, which is almost never "what did Connect send?" and almost always "why did nothing reach this customer?"
Both sorts of no appear here: a person declining a held item, and a gate stopping an action the mode permitted — suppression, a block on the contact, a spent limit, a provider that cannot carry the message. Each carries its reason, so the difference between a compliance stop and a capacity stop is visible without opening anything else.
Questions it answers well#
- Who released this? Months later, with a name attached, rather than a shrug.
- Was that Connect or a person? Including the third case — the Connect Assistant acting on somebody's request, recorded as itself.
- Which setting was in force? The rule at the time of the decision, not the rule now.
- Did it actually arrive? The provider's acknowledgement, distinct from the fact that Connect handed the message over.
- Why did nothing happen? The refusal and its reason, which is the entry most other products do not keep.
It answers one class of question badly, and knowing that saves time: it is not the message archive. What was said lives on the conversation. The log records the decision about the message, which is a deliberately narrower and more durable thing.
Who can read it#
The log is workspace-scoped like every other record. A workspace sees its own decisions and no others, and that boundary is enforced three times over — by the allowlist in front of the customer API, by the workspace kernel in the ORM, and by row-level security in PostgreSQL. Reading somebody else's decisions is not a permission that exists to be granted.
Within a workspace, access follows the same rules as the rest of the product; Who may read the audit record covers that specifically. Both audiences have the same screen over the same implementation — an Owner and a customer are looking at one feature, not two.
Questions#
Does the log contain the text of what was sent?
It records the decision, its rule, its actor and its outcome. The wording lives with the conversation, where it can be read in context alongside everything else on the thread.
Are the Connect Assistant's actions recorded separately from mine?
Yes. It acts under rights narrower than a person's and its work is recorded as its own. A log that attributed its actions to whoever asked would answer the accountability question wrongly.
Will the log show a send that was handed over but never arrived?
That is exactly the gap it is built to show. Handing a message to a provider and the provider acknowledging it are two different events, and the state between them is recorded as uncertain rather than as success.