Let AI draft the project status. Make the evidence decide what it can say.

Project reporting is becoming an AI task before it becomes a controlled process

Microsoft's October 8, 2026 Customer Zero case describes product managers using AI and agents for planning, reporting, data quality, and cross-team communication. Atlassian now provides a governed artifact layer for work created by agents. In a current r/projectmanagement discussion, practitioners described weekly reports assembled from email, meetings, Planner, and work-breakdown data. The use case is real because reporting consumes time and the inputs are scattered.

The risk is equally concrete. A status report is not merely a summary. It is a management record that can trigger funding decisions, staffing changes, customer communication, contract escalation, and executive intervention. If the draft mixes a Friday schedule with Monday actuals, treats an unapproved change as committed scope, or rewrites a tentative meeting comment as a milestone promise, the prose may be polished and the project state wrong.

Microsoft's responsible-AI documentation uses the right product boundary: its project status report is an editable starting point, and every narrative section should be reviewed before distribution. That boundary should be strengthened operationally. Review starts before narrative. The team must first freeze the reporting cut, identify authoritative sources, reproduce calculations, expose conflicts, and identify which judgments belong to accountable owners.

Freeze the reporting contract before collecting updates

A project can have several plausible "current" states. The schedule may update continuously, the ledger may close monthly, vendors may report on Thursday, and risk owners may attest on Friday. A weekly report needs one explicit status date and a cut-off policy for evidence that arrives before or after it. Microsoft Project's status-date behavior illustrates why this is not clerical detail: actual and remaining work are positioned relative to that date.

The contract names the approved baseline, working calendar, reporting currency, accounting period, scope version, RAG definitions, materiality thresholds, forecast method, audience, and decision rights. It also states whether late evidence is excluded, included with an exception, or carried into the next cycle. Without this contract, the model cannot distinguish a legitimate update from a temporal mismatch.

reporting_contract:
  project_id: OPS-2048
  status_at: "2026-10-09T17:00:00+08:00"
  schedule_baseline: "BL-2026-09-01-v3"
  budget_baseline: "FY27-APPROVED-v2"
  currency: "USD"
  cost_period_end: "2026-09-30"
  schedule_freshness_hours: 24
  risk_freshness_days: 7
  rag_policy: "PMO-RAG-2026-04"
  materiality:
    cost_variance_pct: 5
    milestone_slip_days: 10
  release_authority: "program-steering-chair"

Version every contract field. If the steering committee changes an amber threshold or approves a rebaseline, the next report should identify the effective decision rather than silently using a different rule. An AI system should never "normalize" project definitions across periods without disclosing the change.

Give each evidence domain an owner and an authority level

Connected tools do not create a single truth. Jira may be authoritative for work items, Microsoft Project for the schedule, an ERP for actual cost, a spreadsheet for the latest forecast, Confluence for decisions, and a risk platform for enterprise risks. Email and meetings may explain why those records changed, but they should not automatically override them.

Treat the report as a temporal join, not a document-generation task. Every source has at least three relevant times: when the event happened, when the source was updated, and when it was extracted. A Friday schedule snapshot and a month-end cost ledger can both be valid while describing different cuts. The reconciliation packet must preserve those times and label a domain stale, pending, or not comparable when the periods do not align. This prevents the model from joining whichever numbers happen to be available into a false current-state picture. It also makes late data operationally visible: the owner can provide an approved estimate, keep the field unknown, or delay release, but the missing period cannot disappear inside fluent prose.

Atlassian Artifacts is useful because it gives agent-created work a central record, versions, sharing controls, and links into Jira and Confluence. It does not decide which source is authoritative or whether a generated artifact is approved. The source register should record owner, extraction time, effective period, version, access class, and authority for every artifact.

Minimize access. A project report may need aggregate resource risk but not employee performance detail; a customer-facing report may need a milestone exception but not privileged legal advice. Prepare audience-specific releases from one reviewed evidence packet rather than giving the model broad access and asking it to redact afterward.

Reconcile numbers and states before generating prose

Schedule, cost, and scope indicators should come from deterministic logic. The model can help explain the result, but arithmetic and state transitions should be reproducible. Preserve the inputs and formula beside every material metric.

def status_metric(actual, baseline, threshold, direction="higher_is_worse"):
    if actual is None or baseline is None:
        return {"state": "UNKNOWN", "reason": "missing input"}
    variance = actual - baseline
    variance_pct = variance / baseline if baseline else None
    breached = variance_pct is not None and (
        variance_pct > threshold if direction == "higher_is_worse"
        else variance_pct < -threshold
    )
    return {
        "actual": actual,
        "baseline": baseline,
        "variance": variance,
        "variance_pct": variance_pct,
        "threshold": threshold,
        "proposed_state": "AMBER" if breached else "GREEN"
    }

Percent complete deserves special scrutiny. It can mean elapsed time, effort spent, deliverables accepted, tasks closed, or an owner's estimate. Record the definition and supporting event. A task at 90% for six weeks is not evidence of near completion. Where possible, use objective states: acceptance criteria passed, milestone signed, environment available, contract executed, invoice posted, or dependency delivered.

Roll forward risks, issues, dependencies, decisions, and actions by stable ID. Every material open item from the prior approved report must be present, closed with evidence, or explicitly superseded. A generated summary should not make an awkward unresolved item disappear because it was absent from the latest meeting.

Conflicts are output, not noise. If the work system says complete, the schedule says unfinished, and the acceptance record is missing, publish an exception for the named owners. Do not choose the most recent field by default. Recency is not authority.

Draft the narrative from released packet fields

Once the evidence packet is reconciled, the model can produce an executive summary, workstream updates, variance explanations, next-period focus, and decision requests. Every material number, milestone, risk, dependency, decision, and forecast should carry a source ID or calculation ID during review. Citations may be hidden in the final executive layout, but they must remain available to the reviewer.

Keep five statement types visually distinct in the review packet: sourced fact, deterministic calculation, accountable-owner judgment, assumption, and recommendation. "Milestone M-14 is 12 days late" can be a calculation. "Recovery by October 30 is achievable" is a forecast judgment. "Add two engineers" is a recommendation. A fluent paragraph must not collapse them into one factual claim.

RAG status is often partly deterministic and partly governed judgment. Apply the supplied thresholds first, then record every requested override with rationale, authority, expiry, and affected claims. A sponsor may accept a risk or approve a recovery plan. The AI may not quietly turn amber green because the narrative sounds optimistic.

Lock the exact release version. Distribution to executives, customers, regulators, or employees is a separate action from approval. Any write-back to Jira, Planner, Asana, Smartsheet, an ERP, or a risk system should preview the destination, field, prior value, proposed value, approver, and rollback path.

Worked example: the project is green in one system and late in another

Assume a workstream lead marks integration testing 100% complete in the task system. The master schedule still shows the test milestone unfinished. The evidence folder contains execution logs for nine of ten required scenarios, and the tenth depends on a vendor certificate due next week. A meeting summary says the team is "basically done." Finance actuals are current only through the prior month.

A weak AI report says: "Integration testing is complete and the project remains green, with only minor vendor paperwork outstanding." The evidence-gated packet produces a different result:

• Completion state: NOT ACCEPTED. Nine of ten scenarios have evidence; the required vendor-dependent scenario is open.
• Schedule state: AMBER under the approved threshold because the milestone is incomplete and the dependency need-by date is breached.
• Cost state: UNKNOWN for the current period because actuals and accruals are not aligned to the status cut.
• Conflict: the task field conflicts with the schedule and acceptance record; the workstream owner must correct or justify it.
• Narrative: "Integration testing has evidence for nine of ten required scenarios. Final acceptance depends on vendor certificate VC-17; current-period cost status is held pending the aligned finance extract."

The better report is less reassuring because the project evidence is less complete. That is the point. Reporting should reveal the state leaders need to govern, not smooth it into the story they expected.

Failure modes and controls

Do not measure quality only by whether leaders liked the summary. Measure unsupported material claims, missed material exceptions, deterministic calculation agreement, stale-source detection, RAG override accuracy, source-link validity, reviewer correction time, distribution errors, and write-back reconciliation. A smoother report can score well on style while making governance worse.

A 30-day shadow pilot

1. Week 1 - contract and baseline: choose one recurring report, freeze definitions, map source authority, and measure the current manual preparation and correction process.
2. Week 2 - evidence packet: run the workflow without narrative distribution. Compare calculations, carried items, conflicts, and exceptions with the approved human report.
3. Week 3 - narrative shadow: let project, schedule, finance, risk, and workstream owners adjudicate each material claim while the normal report remains authoritative.
4. Week 4 - controlled release: release one approved version to a limited audience. Keep automatic system writes disabled; test field-level previews and rollback separately.

Segment errors by source system, workstream, metric, report section, data freshness, and audience. Stop the pilot if a material schedule, cost, scope, risk, dependency, decision, or confidentiality error reaches a released draft. Time saved matters only after the evidence and authority gates pass.

Human release checklist

Frequently asked questions

Can AI create a project status report?

Yes, as a draft from a reconciled evidence packet. It should not choose the reporting cut, resolve missing facts, change definitions, approve forecasts, or distribute the report. Microsoft likewise describes its generated project report as an editable starting point that requires project-manager review.

Should email and meetings be included?

They can explain events, record explicit commitments, and surface emerging risks. They should not override an approved schedule, ledger, change register, or decision record without the organization's defined process. Preserve the difference between supporting evidence and system authority.

Can AI choose the project RAG status?

It can calculate a proposed result from approved thresholds and show the inputs. Accountable humans decide whether an override is valid, document the rationale and authority, and approve the exact release. The model cannot waive a breach because the recovery narrative is persuasive.

What is the minimum viable pilot?

Use one recurring report across at least one full reporting cycle. Keep the existing human process authoritative, compare field-level evidence and calculations, classify corrections, and do not enable automatic distribution or write-back until the release criteria pass.

Is this a replacement for project-management judgment?

No. The workflow removes evidence archaeology and arithmetic from the narrative step so project managers can focus judgment on tradeoffs, recovery choices, stakeholder communication, and escalation. Accountability remains with named professionals.