Capacity confirmation

What this worksheet records

Capacity confirmation is dated and project-specific. Identify the request, quantity and application, then distinguish the dates requested by the buyer from those confirmed by the actual provider. Record assumptions about artwork release, material availability and other prerequisites. A longstanding capability description cannot establish space in a current schedule. If the provider has not answered, leave its dates empty and keep the confirmation task visible instead of importing a generic advertised lead time.

Complete and review it

Ask the provider to name the relevant conditions and the person responsible for the statement. Preserve the confirmation source and date so changes can be reviewed against the same baseline. When quantity, material or artwork timing changes, request a fresh response where necessary. A provisional capacity statement should remain separate from accepted commercial scope; neither the platform nor a buyer can convert it into an order acceptance simply by changing a local status.

Field definitions

• capacity_record_id: A stable identifier for this capacity record, used to connect related rows without merging unrelated records.
• request_id: A stable identifier for this request, used to connect related rows without merging unrelated records.
• provider_legal_entity: The actual party for provider legal entity, with its responsibility or rights source identified; do not substitute the platform brand.
• required_quantity: The number required by the current source requirement, not an inferred available quantity.
• application: The actual boundary of application for this row; name inclusions and exclusions instead of implying unlimited applicability or access.
• requested_start: The actual requested start relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• requested_finish: The actual requested finish relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• provider_confirmed_start: The actual provider confirmed start relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• provider_confirmed_finish: The actual provider confirmed finish relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• assumption: The actual assumption relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• exclusion: The actual exclusion relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• confirmation_date: The actual confirmation date, with date format or period meaning explicit; distinguish requested, planned, confirmed and observed values.
• confirmed_by: The named person or agreed role responsible for confirmed by; confirm its real scope rather than assuming authority from a typed name.
• evidence_reference: The actual attributable source for evidence reference; a reference is not evidence that a decision was authenticated or its content verified.
• acceptance_state: The current acceptance state supported by the record, preserving unknown, proposed and confirmed outcomes as distinct states.

Prepare a deliberate export

Capacity details can be commercially sensitive and should not be shared with competing providers. Give authorised planners the relevant confirmation and conditions. This CSV records user-supplied information and does not book a factory slot, reserve stock or bind a provider.

Take it to the next job

• Separate requested dates from provider-confirmed dates.
• Keep prerequisites and exclusions beside the capacity statement.
• Reconfirm affected commitments after a requirement changes.