Engineering · Coordination
Echo
Reply by email. Keep the context.
01
In plain English
- What it is
- A way to bring a supplier’s email reply into the relevant project task.
- How it works
- A supplier would reply to a project email as usual. Echo would place their response beside the right task, showing who sent it and holding uncertain messages for someone to check.
- Why it matters
- To keep useful project information visible to the team instead of scattered across individual inboxes.
02
The working model
A valid delivery envelope can carry an unexpected sender. Routing confidence does not grant authority.
The boundary that matters Imported email is untrusted contribution content. A reply cannot approve work or change project state by itself.
Two paths: Standard flow and Unexpected sender · 5 stages each
03
How it fits together
A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.
Read the diagram source
%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
accTitle: How Project Echo works
accDescr: A supplier replies by email. Signal verifies the delivery source, avoids repeated imports and checks which task and sender the reply belongs to. A clear match becomes a safely displayed task contribution with its original source retained. An uncertain match waits for the project manager to confirm it. Imported email does not approve work. This is a proposed concept.
A(["Supplier<br/>Replies by email"])
B("Email intake<br/>Checks source and duplicates")
C{"Sender and task<br/>clearly matched?"}
D("Prepare reply<br/>Keep its source visible")
E("Project task<br/>Receives the conversation")
X("Project manager<br/>Reviews an uncertain match")
A --> B
B --> C
C -->|Clear match| D
D -->|Information, not approval| E
C -->|Uncertain| X
classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
class A human;
class B,D work;
class C decision;
class E result;
class X exception;
04
The case study
Participation should follow the conversation, while uncertain routing remains a visible decision.
The problem
A supplier replies with a useful delivery constraint. That information stays in someone’s inbox while the project task continues to show an incomplete story.
The insight
Email can be an input channel to the project, provided routing confidence and sender identity are treated as separate concerns.
The system
The proposed inbound pipeline verifies provider webhooks, deduplicates events, and resolves a task-specific reply address. It removes quoted history conservatively, sanitises displayed content, and holds messages with uncertain routing or identity for review.
The rationale
External contributors can use their existing habits while the project retains shared context and source attribution.
Responsibilities
- Inbound email
- Verified webhook envelope; untrusted message content.
- Routing pipeline
- Deduplicate, resolve task, sanitise, and assess uncertainty.
- Project context
- Attributed contribution or explicit human review.
The boundary
An email address or routing token is not sufficient authority to change project state. Imported replies are untrusted contributions.
The trade-off
Aggressive quote removal makes replies cleaner but can discard meaning. Preserve the original source for inspection and expose uncertainty instead of guessing.
When it fails
A webhook is delivered twice
Use durable provider event and message identities to prevent a retry from creating a second task comment.
The sender is unexpected
Hold the contribution for review instead of assigning it the authority of the originally invited recipient.
The route is ambiguous
Keep the message in an unresolved queue with source context. Never attach it to a merely plausible task.
Evidence Design proposal · local demonstration uses synthetic data