Weekly reporting lags when Linear, GitHub, Slack and Notion activity has no explicit meaning.
An automated project status report should automate bounded evidence collection and a reviewable first draft, not delivery judgment, client wording, approval or send authority.
Documentation-led guidance; no client case or tested deployment.
This article owns report assembly and approval. Which system is the authority for each fact is part 3 of this guide; turning meeting notes into tracked tasks, the upstream of much of this activity, is part 1. The full build path is on the guide page.
The answer in 60 seconds
- Collect authorised signals for one reporting period.
- Normalise them without losing native identity or links.
- Classify facts, changes, blockers and missing evidence.
- Draft a client-readable proposal with its uncertainties.
- Require delivery-owner review of meaning and wording.
- Publish/send only after approval for the exact version and channel.
Keep gaps visible. Fact, interpretation and approval differ.
In this article
- Why activity becomes a misleading status
- Give each source a reporting contract
- Collect bounded signals for one period
- Normalise without erasing provenance
- Separate activity from delivery meaning
- Draft the update with evidence
- Put a delivery owner before the client
- Roll out narrowly and monitor gaps
1. Why activity becomes a misleading status
Tools record events. A delivery owner interprets them against the plan, acceptance conditions and client commitments.
Keep five meanings separate:
- observable activity: recorded event or state;
- progress: movement against plan;
- readiness: named gates pass;
- client impact: evidence supports an effect;
- contractual completion: acceptance conditions are recorded.
A closed issue, merged pull request, Slack thread or Notion change is evidence. None alone establishes progress, readiness, client impact or contractual completion. Product state needs accountable interpretation.
2. Give each source a reporting contract
An aggregate view should not become another editable authority. Give each system a bounded role; authority rules decide conflicts.
| Role | Responsibility | Preserve | Not | Human responsibility |
|---|---|---|---|---|
| Linear | Work plan and state | ID, state, owner, time, link | Delivery proof | Confirm meaning |
| GitHub | Change and release evidence | Repo, ID, state, ref, time, link | Deployment/value | Confirm meaning |
| Slack | Conversation context | Channel, thread, time, mutation | Approved decision | Separate noise |
| Notion | Decisions, reports, drafts | Page ID, state, link | Complete coverage/approval | Resolve conflicts |
| n8n | Collect, map, route, review | Execution, error, replay | Send authority | Operate failures |
| Delivery owner | Interpretation and approval | Rationale, correction, decision | Inferred approval | Decide handoff |
Linear exposes issues, projects, milestones, cycles, workflow states, project status, relations and comments as inputs, not client conclusions. OAuth identity and scopes establish access, not approval.
GitHub fine-grained permissions are endpoint-specific. Slack OAuth scopes bound access, not authority. Notion sees shared content; its search finds shared titles, not unrestricted workspace full text. AI Connector documentation is context, not tenant proof.
3. Collect bounded signals for one period
Define start, end and timezone. Preserve native ID, URL, provider time and collection gaps.
- Linear: search has modes and limits. Its GraphQL API can return response-level errors or partial data; webhooks are scoped, signed, retried and may be disabled after failures. Inspect both before claiming coverage.
- GitHub: commits, pull requests, issues and releases expose different states; issue results can include pull requests. Lists support filters and qualifiers, not complete visibility. Delivery inspection is bounded; failed deliveries are not automatically redelivered.
- Slack: search, history and replies depend on token, scope, membership, pagination, rate and results. Retention can remove history. Editing policy, change and deletion events expose mutability, not substantive correction.
- Notion: data-source queries support bounded filters, sorts and pagination. Page retrieval omits complete content; comments are separately paginated.
- n8n: a published workflow can use a Schedule Trigger or Webhook. Its Linear, GitHub, Slack and Notion nodes expose defined operations and credentials, not complete coverage.
Map access, history, webhook, retention, pagination and partial-response gaps to missing or uncertain, never “no activity”.
4. Normalise without erasing provenance
Use this exact minimum schema:
project_id, period, source_system, source_id, source_url, event_type, occurred_at, owner, fact, authority, confidence, client_visible, review_state.
Keep source_id native and unknown owners unknown. occurred_at is not collection time; authority names the conflict rule; confidence is not approval.
n8n Merge and Edit Fields can combine, overwrite or discard fields. Define clash and unmatched-item rules; transformation is not verification.
5. Separate activity from delivery meaning
| Layer | Example | Owner | Boundary |
|---|---|---|---|
| Sourced fact | “PR 184 has the observed merge state” | Native source | Not deployment, value or acceptance |
| Delivery interpretation | “The change advances the milestone, subject to tests” | Delivery owner | Not approved wording |
| Approved client statement | Final copy for one version/channel | Authorised owner | Not another version |
Preserve contradiction, deletion, uncertainty and unresolved authority. Linear’s maintained project status and updates record an owner’s view; issue activity does not resolve health or approve wording.
Compare with the baseline. Route progress, readiness, risk, impact and completion to the owner.
6. Draft the update with evidence
A reviewable client-status proposal exposes exactly ten fields:
| Field | Required behaviour |
|---|---|
period | Reporting window |
sourced_facts | Native ID, link, time |
changes | Difference from baseline |
blockers | Evidence, owner, impact |
decisions | Approved, not discussed |
risks | Owner assessment |
missing_evidence | Missing, stale or contradictory |
next_steps | State and owner |
owner | Accountability or unknown |
approval_state | Draft, changes, approved, rejected, expired |
Notion can create or update a page with required access; materialisation is not approval. n8n AI Transform can generate read-only transformation code on n8n Cloud; validate it.
Illustrative Atlas week, not an IZZY client case.
| Stage | Atlas reference action | Review state exposed |
|---|---|---|
| Collect | Retrieve authorised period evidence | Access, retention, webhook gaps |
| Normalise | Map thirteen fields | Unknown owners, times, conflicts |
| Classify | Separate facts/gaps | No health conclusion |
| Draft | Assemble ten linked fields | Contradictions visible |
| Review | Correct meaning/wording | Version/channel decision |
| Publish/send | Stay closed pending gates | No inferred approval |
7. Put a delivery owner before the client
The owner reviews version, period, coverage, gaps, wording, recipients and channel. Record approver, time, state and expiry; material change reopens review.
n8n can return a webhook response; that is not publication authority. Send Email can send or wait for a response. Slack approvals can capture and restrict responders; an empty approver list lets any viewer respond. The feature is preview, rolls out gradually, may be unavailable on an instance and, n8n says, should not be relied on in production. Business authority remains independent. A human fallback and tool review show possible mechanics, not a business approval contract.
For general agent policy, see IZZY’s permissions, security controls and production governance.
8. Roll out narrowly and monitor gaps
| Stage | Permitted behaviour | Stop or narrow when |
|---|---|---|
| Shadow comparison | Read one project/period; draft; do not send | Authority, traceability, coverage or review fails |
| Approval-required handoff | Prepare one version; hold send for review | Version, approver or channel control fails |
| Bounded recurring reporting | Repeat tested sources, period and contract | Source, schema, channel or ownership changes |
n8n’s Error Trigger and execution views expose bounded failure evidence; deleting a workflow deletes its execution history.
Monitor collection, stale state, replay, unmatched records, version, approval, blocked sends and operator. Keep a stop route; invent no threshold or SLA.
Conclusion: automate evidence assembly, not client judgment
Automate evidence assembly while exposing interpretation, provenance, gaps and exact-version approval.
Atlas is illustrative. No implementation or result was tested.
Map one reporting workflow
Bring six inputs: your current report, the source systems, the manual checks, the approval owner, the channel and one misleading status. IZZY will map evidence, interpretation and approval, then scope a bounded pilot. Standardising the report or the authority rules may come first.
This is exactly the scope of our n8n AI Automation service.
Frequently asked questions
It collects, normalises and classifies bounded evidence, drafts, requires owner review and only then permits publish/send. It does not decide project health.
No. Recorded states need owner interpretation against the plan and acceptance conditions.
Only as bounded evidence under the authority contract. Volume is not authority.
Not in this IZZY design. Publish/send stays closed until the named delivery owner approves the exact version and channel.
Keep it visible, block unsupported conclusions, route it to the owner and close the handoff where required.
Sources and method
Research was checked on 2026-07-28 and every link re-verified on 2026-09-07, using current official Linear, GitHub, Slack, Notion and n8n documentation. Official links sit beside product claims. The workflow, schema and approval contract are IZZY guidance.
No live tenant, credential, API response, webhook, n8n execution, approval callback, Atlas dataset, report accuracy, client outcome, recipient channel, CMS entry or publish/send was tested. Documentation can change after the check date.