Documents, calendars and code: connectors for delivering the promise

Once a customer accepts a project, the work spreads across documents, meetings, tickets and code. The operating platform should help coordinate those artifacts without pretending that a checked task box proves the customer received the promised outcome.

For the document-search pilot used throughout this series, the delivery loop needs a scoped agreement, access checklist, kickoff meeting, implementation tasks, test evidence and an acceptance record. Each artifact lives in a tool with its own identifiers and revision model. The connector's job is to preserve those relationships.

A deliverable needs a stable business identity

Use a deliverable ID that survives file renames and tool migration. Link it to the provider file ID, revision, content digest, owner, classification and accepted milestone. A document title such as “Final proposal latest” is not a versioning strategy.

{
  "deliverable_id": "pilot-017/acceptance-report",
  "provider": "document-store",
  "provider_file_id": "file-opaque-42",
  "revision": "r7",
  "content_digest": "sha256:recorded-at-ingestion",
  "milestone": "pilot-017/acceptance",
  "review_state": "PENDING",
  "source_release": "release-017-rc2"
}

The digest above is a placeholder in an API sketch; a real record contains the computed digest. The important relationship is that acceptance evidence names the release and revision it actually evaluates. Replacing the file contents after approval must not leave an old acceptance record looking current.

Generate documents from structured commitments

The commercial record should drive the proposal's price, scope and dates. A model may draft explanatory prose, but structured terms should come from validated fields. Render the document, compare its extracted terms with the approved record and preserve the output revision.

The same approach applies to status reports. Gather task state and evidence references first, then write the narrative. A report saying “deployment complete” should point to the environment and release receipt. A generated paragraph cannot serve as its own proof.

When a source file changes, invalidate downstream summaries or mark them stale. If a client edits acceptance criteria in a shared document, create a proposed scope change rather than silently updating the signed commitment.

Scheduling is a negotiated constraint problem

A calendar tool can check availability and propose slots. It also needs duration, timezone, participants, location or meeting link, working-hour constraints and the purpose of the meeting. “Book something tomorrow afternoon” is underspecified if the participants work in different regions.

Use timezone-aware datetimes and retain the named timezone for future interpretation:

from datetime import datetime, timedelta
from zoneinfo import ZoneInfo

start = datetime(2026, 10, 6, 14, 0, tzinfo=ZoneInfo("Asia/Singapore"))
end = start + timedelta(minutes=30)
assert start.isoformat() == "2026-10-06T14:00:00+08:00"
calendar_intent = {
    "subject": "pilot-017/kickoff",
    "start": start.isoformat(), "end": end.isoformat(),
    "timezone": "Asia/Singapore",
    "attendees": ["[email protected]"],
    "status": "PROPOSED",
}

Availability can change between suggestion and insertion. Refresh it close to execution and handle conflicts explicitly. A successful API insertion is not evidence that every attendee accepted. Track the provider event identity and subsequent responses. The Calendar insert API creates events; the business workflow still owns review, conflict handling and meeting purpose. Calendar event insertion.

Issue trackers coordinate work, not truth

Create tickets from an approved work order with acceptance criteria and a link to the relevant milestone. Keep one business task identity across retries so a timeout does not create several copies. Store the provider ticket identity when known and reconcile before repeating an uncertain creation.

A ticket's “done” status is useful evidence of a team's assertion. It is not necessarily proof of deployment, customer acceptance or payment. The delivery loop should require the relevant evidence categories rather than infer all of them from one status field.

For a code change, the connector can open a pull request in an allowed repository and branch. Build and test results become evidence linked to the exact commit. Production release authority remains a separate capability. An agent allowed to draft implementation work does not automatically get permission to merge or deploy it.

Verify incoming delivery evidence

Webhook signature verification establishes that an event arrived through the expected integration boundary. Verify the raw body before parsing and use the provider's documented scheme. The lab includes a GitHub-style HMAC verifier:

import hashlib, hmac
from company_lab.connectors import verify_github

body = b'{"action":"completed"}'
secret = b"local-test-secret"
signature = "sha256=" + hmac.new(secret, body, hashlib.sha256).hexdigest()
assert verify_github(secret, body, signature)
assert not verify_github(secret, body + b" ", signature)

This verifies integrity, not the business meaning of the event. Also validate repository identity, installation scope, event type, delivery deduplication and the commit under evaluation. GitHub webhook validation.

Accept the release that was actually tested

The reference delivery_ready function requires the necessary evidence to name the current release. A passing result from yesterday's build should not satisfy today's acceptance gate after a relevant change.

from company_lab.business import delivery_ready

required = {"tests", "acceptance"}
evidence = {
    "tests": {"release": "r2", "ref": "run-41"},
    "acceptance": {"release": "r1", "ref": "review-12"},
}
assert not delivery_ready(required, evidence, "r2")

The scenario to test is a kickoff moved after a scope amendment, followed by a new release whose acceptance report still references the previous version. The correct platform keeps the meeting and evidence relationships current and blocks completion until the mismatch is resolved. This is the practical value of connecting the tools through a shared commitment record.