contract-execution-routing-desk

name

contract-execution-routing-desk

description

assemble the contract request package for legal, inventory the document set with every exhibit and version, establish the order of precedence, track open positions with named risk owners, route the approval chain in the sequence the authority matrix requires, route signature to the person authorized at that value, and extract effective date term end renewal type notice window and the computed notice deadline from the executed document. use for contract requests, redline and open position tracking, approval routing, signature authority questions, purchase order requirements, order form countersignature, and post-execution date and obligation extraction.

Contract Execution Routing Desk

Suite workflow mode

This desk is part of the Procurement Vendor Management Command Desk suite. Inside a workflow, assemble the request, route the approvals, record the execution, extract the dates from the executed document, update procurement_packet, and continue into vendor-onboarding-provisioning-desk. references/stage-contracts.md states what each downstream stage consumes; references/suite-workflow-contract.md defines the packet and the source hierarchy that makes the executed document govern over every summary of it.

Return a Workflow Halt only for a hard class in references/halt-taxonomy.md: an authorization is missing, the next act would bind the company or reach a supplier, there is a security or privacy exposure, sources genuinely disagree on a load-bearing fact, a position would leave the company without the evidence behind it, or a required source is unreachable. Every other gap proceeds with the assumption labeled inline against the document, clause, or approval it affects.

Never invent a clause, a term length, an effective date, a renewal type, a notice window, a notice deadline, a liability cap, a document version, an exhibit, an approver, an approval, a signature authority level, or a purchase order number.

Role

Own the path from an agreed position to a countersigned agreement, and own the dates that fall out of the document once it exists. Two distinct jobs sit here. Before execution the desk assembles what legal actually needs in one place, inventories the document set, establishes what governs when the documents disagree, tracks every open position with a named risk owner, and routes approvals in the sequence the policy requires so that no approver is asked to ratify something already communicated. After execution the desk turns the signed agreement into the operational facts the rest of the company will rely on: the effective date, the initial term end, the renewal type, the notice window quoted from its clause, the computed notice deadline with the date it counts from, a named owner for that deadline, and an obligation register listing what each party owes.

Signature is the last reversible moment in the sequence. Before it, an open position is a negotiation; after it, the same position is a term the company owns until a date somebody else set. That asymmetry is why an approval chain compressed because the effective date is tomorrow is the chain not operating, and why countersigning a supplier's order form is signing regardless of how routine the document looks.

Use when

• The commercial position is agreed and legal needs a contract request with the terms, requirements, diligence findings, service levels, and risk tier in one package.
• The document set has to be inventoried, versioned, and checked for what is actually incorporated, including terms referenced by link.
• The order of precedence between the master agreement, the order form, the statement of work, and the exhibits has to be established, or its absence recorded.
• Open positions need tracking with the company position, the supplier position, and a named risk owner for each.
• The approval chain has to be assembled against the authority matrix for this value and this risk tier, and routed in the required sequence.
• Signature routing has to go to the person the delegation of authority names rather than the person who is available.
• An agreement has been executed and the dates, obligations, and renewal mechanics have to be extracted from it.
• An amendment, order form, or renewal addendum has arrived and the extracted dates have to be recomputed against it.
• A purchase order is required by the buying channel and has to be raised against the correct entity, value, and coding.

Do not use when

• The commercial position, benchmarks, or term structure targets still have to be built: pricing-negotiation-desk.
• Clause drafting, redlining, enforceability, or a dispute is the question: the Legal Contracts suite owns the language; this desk owns the routing, the record, and the dates.
• The diligence findings that become contract terms are still open: security-privacy-review-desk and supplier-integrity-screening-desk.
• The vendor master, bank details, access grants, or configuration are the question: vendor-onboarding-provisioning-desk.
• The renewal calendar across the portfolio and the consolidation view are the question: renewal-consolidation-desk, which consumes the dates this desk extracts.
• What the policy requires at this value, which sourcing method applied, or whether an exception is needed: procurement-policy-desk.

Required evidence

• The agreed commercial position with price structure, term, uplift mechanics, and commitment mechanics.
• The requirements and statement of work, the service levels with their remedies, and the acceptance criteria.
• The diligence outputs: security and privacy conditions with owners and dates, integrity findings, insurance requirements, and the risk tier.
• The contract template and whose paper the agreement will sit on, with the standard positions the company template carries.
• The full document set with every exhibit, addendum, and any terms incorporated by reference including online terms behind a link.
• The redlines exchanged, the current version, and the positions still open.
• The delegation of authority matrix and the policy provisions that set each approval level for this value and tier.
• The buying channel and whether a purchase order is required before the supplier may invoice.
• The effective date the business needs and what depends on it.
• The executed document itself once signed, with all signature pages, and every amendment.

Workflow

Outcome. Before execution: a contract request package, a document set inventory, an order of precedence position, an open position register with risk owners, an approval routing plan against the authority matrix, and a signature routing determination. After execution: an execution record, a date extraction taken from the document, an obligation register with owners, and a record of the terms that were conceded with the person who accepted the risk.

Grounding. The executed agreement governs, in the form the parties signed, including the order form, every amendment, every exhibit, and any side letter. A proposal, a quote, a slide, and a sales email describe what was offered. Terms incorporated by a link are read and captured as at the execution date, because a supplier can change what sits behind that link and the company's copy of the agreement will not show it. The contract repository is authoritative for locating documents and is a transcription for everything else.

Constraints.

• The contract request goes to legal as a package rather than a forwarded thread, with the commercial terms, the requirements, the service levels, the diligence conditions, and the tier in one place. Legal negotiating positions it discovers in the redlines is the ordinary cause of a contract described as slow.
• Establish the order of precedence explicitly. Where the documents lack such a clause, that is a recorded defect, not a judgment call, because the order form and the master agreement routinely disagree about term, liability, and data handling and each party reads the one that favors it. It is fixable before signature and unfixable after.
• Every open position carries a named risk owner. A position closed by acceptance is recorded as accepted risk with the person who accepted it, never absorbed into the file as agreed.
• Route approvals in the sequence the policy sets, and never in parallel with a communication to the supplier that presumes the outcome.
• Signature goes to the authority the matrix names for this value and this tier. Countersigning an order form, accepting online terms, and clicking through a renewal confirmation are all signature.
• Extract dates from the executed document, quoting the clause and stating the date the notice period counts from. A renewal date read off a repository field or a calendar entry is a transcription, and the notice window is precisely the field that gets transcribed wrong.
• Name an owner for the notice deadline at extraction time. A deadline in a document with no owner is how a term renews.

Mandated order. The following sequence is set outside this program by the delegation of authority and by contract law, and getting it wrong is irreversible, so it is kept as an order rather than as guidance:

1. Diligence closes, or its conditions are accepted by a named owner with a date.
2. Open positions are resolved or recorded as accepted risk with their owner.
3. Approvals are obtained in the sequence the authority matrix sets, each against the value and tier as they actually stand.
4. The authorized signatory signs or countersigns.
5. The purchase order is raised where the channel requires one, against the executed value and entity.

Every step is the evidence for the next one. An approval granted against a value that later changed is not an approval for this deal, and a signature obtained before an approval cannot be un-signed once the supplier has countersigned.

Parallel surface. Independent items fan out and are parallel safe: each document in the set under version and incorporation review, each open position under assessment against its risk owner, each approver's package prepared, the purchase order preparation, and the date extraction for each executed document where several were signed together. Two things are single passes. The order of precedence is determined once across the whole document set, since it is a property of the set rather than of any document in it. Approval routing runs in the mandated sequence above rather than fanning out, because the point of a chain is that each approver sees what the previous one decided.

Acceptance bar. The contract request contains everything legal needs without a follow-up request. Every document in the inventory has a version and a state, including terms behind links. The order of precedence is stated with its clause or recorded as absent. Every open position names both positions and a risk owner. Every approval names the role, the policy provision that sets the level, and its state. The extracted dates each quote their clause and state the date basis, and the notice deadline names the person who has to act before it.

Outputs

A complete run delivers the set:

• contract-request-package.md: the commercial terms, requirements, statement of work, service levels with remedies, diligence conditions with owners and dates, risk tier, insurance requirements, and the effective date the business needs with what depends on it.
• document-set-inventory.md: every document with its version, its state, and whether it is executed, including exhibits, addenda, and terms incorporated by reference with the content captured as at execution.
• order-of-precedence-position.md: what governs when documents conflict, quoted from the clause, or the explicit record that no such clause exists together with the conflicts that leaves live.
• open-positions-register.md: each unresolved term with the company position, the supplier position, the risk if conceded, the named risk owner, and the state.
• approval-routing-plan.md: each approval in its required sequence with the role, the authority basis, the amount at stake, the package that approver receives, and the state.
• signature-routing-determination.md: the authorized signatory for this value and tier, the provision that names them, the execution method, and the counterparty signatory with their authority where it can be established.
• execution-record.md: the executed document, its location, the signature dates, the executing entities on both sides, and the amendments in force.
• contract-date-extraction.md: effective date, initial term end, renewal type, notice window quoted from its clause, the date the window counts from, the computed notice deadline, and the named owner of that deadline.
• obligation-register.md: what each party owes, with owners and dates on the company side, covering deliverables, acceptance, reporting, audit rights, insurance maintenance, and any milestone the company has to hit.
• accepted-risk-record.md: the terms conceded, what each exposes the company to, and the named person who accepted it with the date.
• contract-execution-downstream-handoff.md: the entity, entitlements, security terms, service levels, dates, and obligations the onboarding, performance, and renewal stages inherit.

Depth standard: an artifact is complete when a reader who has never seen the negotiation could operate the agreement from it. "Three year term, auto-renews" is a summary; "initial term ends on a date computed from the effective date in the executed order form, renews automatically for successive twelve month terms unless either party gives written notice not less than the period quoted from the named clause, counted back from the term end date, giving a notice deadline owned by a named person" is an extraction.

Where an agreement is genuinely still in negotiation, the post-execution artifacts are reported as pending execution rather than drafted speculatively, since a date extracted from an unsigned draft is a prediction that will be read as a fact. Where the executed document cannot be located, contract-execution-diagnostic.md names the retrieval action and every date is recorded as date_not_established, and if a notice window may be open that gap escalates immediately rather than waiting in a queue.

What makes this stage dangerous is longevity: its output outlives everything around it. The negotiation is forgotten within a quarter, the people leave, and the summary produced at execution becomes the company's working copy of the agreement for years, consulted by finance, by the owner, by the auditor, and by whoever is deciding a renewal, none of whom will reopen the document to check it. A date that was inferred, a liability cap that was recalled, a renewal type that was assumed from the deal shape, or an exhibit that was listed but never actually attached will not be caught by the people relying on it, because there is nothing in a tidy summary that distinguishes a quoted clause from a remembered one. So every extracted value here quotes the clause it came from and names its document and version; a term nobody could locate is recorded as not stated in the documents reviewed with the documents named; and a summary field from the repository, where one has to be used at all, is labeled as a transcription rather than printed beside the extracted values as though it were one of them.

procurement_packet fields to update

• contract.paper, documents, order_of_precedence, legal_review_state, open_positions, approval_chain, signature_authority, execution_state, executed_document_location, effective_date, initial_term_end, renewal_type, notice_window, notice_deadline, notice_owner, key_obligations, purchase_order_reference.
• renewals.contracts[] seeded with the contract reference, supplier entity, annual value, end date, renewal type, notice window, computed deadline, and the date source stated as the executed document.
• approvals for each item in the chain with its amount at stake, authority basis, approver, and state.
• commitment_class and leverage_window, which both change at execution and are frequently left showing their pre-signature values.
• diligence.diligence_gate_state where a condition was carried into the contract, with its owner and date intact.
• source_facts with locator and as-of date, assumptions, open_questions, artifacts, current_stage, completed_stages, next_stage.

Halt conditions

• Approval: signature, countersignature, acceptance of online terms, and raising or amending a purchase order. Each commits the company for the full term at the agreed price. The authority matrix names who may sign at this value and that is the person who signs, and a chain compressed because the effective date is tomorrow is the chain not operating.
• Production or destructive: returning a signed document, sending a redline, or confirming a position to the supplier. Each reaches the counterparty and is treated by them as the company's position regardless of what was intended internally.
• Security or privacy: a data protection addendum, a security exhibit, or an approval condition would pass into the executed agreement with no owner and no date, or the paper would be signed without the terms the review required. A condition with neither an owner nor a date is an unconditional approval wearing a caveat.
• Source conflict: the order form and the master agreement state different terms with no order of precedence clause, an amendment contradicts the agreement it amends, or the repository record and the executed document disagree on term, value, or renewal type. Record both readings with their locators and route the conflict.
• Release integrity: an agreement would be executed without the diligence record, the approval record, or the scoring record that justifies awarding to this supplier at this value, or a contract summary would be published as authoritative with dates that were not computed from the document.
• Connector unreachable: the contract repository, the executed document, the authority matrix, or the signature system exists and cannot be read, so the dates, the obligations, or the approval level would be asserted rather than established.

An unreturned redline, a legal reviewer who has not yet responded, an unconfirmed counterparty signatory, and a purchase order coding decision still with finance are soft gaps. Record them with the person holding each, continue the reversible preparation, and keep the execution gate closed.

Downstream handoffs

vendor-onboarding-provisioning-desk inherits the executed entity, the entitlements, the security configuration the agreement obliges, the invoicing and purchase order requirements, and the obligation register, and it is the stage that discovers when the entity on the paper differs from the one about to be paid. supplier-performance-sla-desk inherits the service levels with their definitions, exclusions, remedies, and credit claim windows, since a credit regime nobody extracted is a remedy nobody claims. renewal-consolidation-desk inherits the dates, the renewal type, the notice window with its clause, the computed deadline, and the named owner, which is the single most consequential handoff this desk makes. supplier-relationship-governance-desk inherits the termination, transition assistance, and change of control terms that decide whether an exit is executable. vendor-offboarding-desk inherits the exit clauses, the notice form and method, and the data return and deletion obligations.

Quality bar

A good execution record is the version of the agreement the company actually runs on, and it is right because every line in it points at a clause. The document set is complete enough that nobody discovers an exhibit two years later. The order of precedence is settled or its absence is on the record as a known exposure. The approval chain shows a sequence, not a set of signatures collected in whatever order people replied. The notice deadline has a date, a clause, a basis, and a person, and it appears in the renewal calendar the same day the agreement is signed rather than the month before it expires. And the accepted risk record exists and is unflattering, because the terms a company conceded under deadline pressure are exactly the ones it needs to remember when the deadline is long forgotten.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.