A supplier can promise delivery on the same date a project milestone is due, while the team still needs time to receive, inspect and prepare the item. A simple date match may look acceptable even when the dependent work cannot begin. The comparison needs the project's approved dependency and readiness rule, not just two dates.
This article proposes a procurement timing-risk brief. It extracts supplier date statements, relates them to approved project items and shows unresolved gaps. It does not determine contractual consequences, predict actual delivery or move milestones automatically.
Identify the dependency before comparing dates
Start with the approved project reference, item reference and milestone version. Record which activity actually depends on the item. A similar description in a supplier schedule does not establish that it serves the same milestone; quantities, locations or work packages may differ.
Ask the project owner what ready means. Delivery may need to precede inspection, assembly or a scheduled installation. The owner supplies any approved preparation duration and calendar convention. Do not invent a buffer because an assistant assumes that projects usually need one.
Keep date-only and timestamp requirements distinct. A required date without a time may not support a precise hour-level conclusion. Preserve the source granularity and ask for clarification where timing matters. Do not create false precision by assigning an arbitrary morning time.
Preserve the status of supplier dates
Record whether the supplier's date is proposed, estimated, confirmed or subject to a stated condition. A forecast can identify a planning concern, but it is not necessarily a confirmed commitment. An accepted revision needs its own evidence and relationship to the earlier date.
OpenAI's Structured Outputs guide supports schema-constrained responses and refusals. A structured extraction can separate item reference, date purpose, status, source and uncertainty. It does not verify that the supplier's wording establishes a commitment or that the project mapping is correct. Source: OpenAI structured outputs
Use exact source references for the relevant statement. If an attachment or page is unreadable, keep the affected date unresolved. Do not infer the missing date from the order sequence or a different supplier's schedule.
Procurement timing-risk brief
Use this complete hypothetical brief. Dates and lead times are fictional planning inputs, approved by the fixture project owner for demonstration. The rule uses calendar dates and does not assert a legal deadline calculation.
Project: TEST-PROJECT-A, milestone schedule version 3. Readiness rule: each item must be received two calendar days before its dependent milestone in this fixture. Supplier status and actual receipt remain separate.
| Item and dependency | Supplier evidence | Approved readiness date | Timing result and owner decision |
|---|---|---|---|
| TEST-ITEM-A required for milestone M01 on 12 November 2026 | Confirmed delivery on 10 November in statement S01 | 10 November under the two-day fixture rule | Recorded date meets readiness rule; owner still checks conditions and actual receipt |
| TEST-ITEM-B required for M02 on 14 November | Proposed delivery on 14 November in S02 | 12 November | Proposed date is two calendar days later than readiness date; procurement requests a supported alternative or project-owner decision |
| TEST-ITEM-C required for M03 on 18 November | S03 says after dispatch without an actual date | 16 November | Delivery timing unknown; hold the timing conclusion and ask for clarification |
| TEST-ITEM-D required for M04 on 20 November | S04 and S05 state conflicting delivery dates | 18 November | Preserve both statements and resolve authoritative date and status before comparison |
Each row stores project and schedule version, item and work-package reference, required quantity, milestone reference, readiness rule and owner, supplier statement and status, interpreted date, source reference, comparison result, uncertainty and next decision owner. Keep approved revisions linked to the earlier brief rather than silently overwriting the comparison.
Decision options: the responsible team can request clarification, review a supplier proposal, consider an owner-approved alternative or assess a project change through the established process. The assistant only prepares these options and supporting evidence. No date is moved, order amended or supplier message sent by generating the brief.
Change handling: recompute affected rows when an approved milestone, preparation rule or supplier commitment changes. Check whether an existing risk item already covers the same dependency before creating another. Mark superseded results and retain the reason for the change.
Acceptance fixtures: a date meeting readiness; delivery on the milestone date despite required preparation; missing delivery date; two conflicting supplier statements; an unapproved milestone revision; and duplicate schedule rows. Verify deterministic date comparison, status labels and held mappings. Do not treat a proposed date as a verified receipt.
The brief is complete when each supplied delivery item has a verified dependency or explicit mapping gap, a traceable timing result and a responsible decision owner. A resolved risk requires the approved decision and later evidence appropriate to that decision, not a reassuring summary alone.
Use calendars as schedule evidence within their limits
Microsoft Graph documents calendars as containers for events, including retrieving events and calendar views. Those operations can supply scheduled dates where the approved project process uses them. They do not establish project dependencies, required preparation duration or supplier fulfilment. Source: Microsoft Graph calendar resource
If the milestone exists in a calendar, confirm its relationship to the approved project schedule and current event status. A cancelled or tentative event should not be treated as an approved milestone without the owner's rule. A calendar date and a planning workbook may disagree; preserve that conflict for the project owner.
Likewise, free/busy availability is a different question from item readiness. An available installation team does not mean the required equipment has arrived. Keep the supplier evidence, preparation rule and staffing availability as separate inputs to the eventual project decision.
Work through normal, missing and duplicate schedules
In a hypothetical normal case, TEST-ITEM-A is linked to M01 and its confirmed delivery date matches the approved readiness date. The brief reports that the recorded plan meets the fixture rule. It still distinguishes the promise from actual receipt and any remaining conditions.
In a missing-date case, TEST-ITEM-C has only a relative statement. The assistant records unknown timing and drafts a precise clarification question asking for the intended delivery date and its status. It does not assume a standard dispatch duration or shift the milestone to fit the uncertainty.
In a duplicate case, two imported rows refer to the same item and milestone. The application can group them under the verified dependency reference while preserving sources. If their dates conflict, it holds the comparison until the owner establishes the authoritative statement. Similar product descriptions alone should not merge different dependencies.
Keep proposed changes separate from executed actions
OpenAI's function-calling guide distinguishes model requests from application execution and returned output. A suggested schedule adjustment is therefore not an approved or completed project change. The selected application must enforce authority for task creation, supplier contact or schedule edits. Source: OpenAI function calling
When the owner approves an action, record the exact affected item, schedule version and payload. Verify the resulting state before updating the brief to complete. An uncertain operation needs reconciliation before retrying, especially where another attempt could create duplicate risk items or conflicting changes.
This brief concerns prospective alignment between supplier plans and project needs. A historical supplier follow-through report compares promises with actual receipts after the event. Keeping those outputs distinct prevents a planning flag from becoming an unsupported performance judgement.
FAQ about supplier schedules and milestones
Can delivery on the milestone date be acceptable?
It depends on the project owner's approved readiness rule and actual timing needs. This fixture requires two calendar days of preparation, so matching the milestone date is insufficient. Do not apply that example duration as a universal rule.
Should the agent move the milestone when delivery looks late?
No. It prepares the timing gap and decision options. The project owner follows the approved change process and considers the relevant dependencies and evidence before any schedule edit.
What if the supplier schedule and calendar disagree?
Preserve the separate sources and identify the decision owner. Confirm which project version and supplier statement apply. Do not resolve the conflict by selecting the newest timestamp automatically.
If your business needs help defining this process, explore Custom AI agents, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.