Design Partner Charters: Bilateral Commitments, Scope Changes, and Expiry Evidence

A target customer agrees to "give feedback every week", and the team commits to delivering an integration in six weeks. In week two the customer's champion transfers roles, and the sample data is late; to keep the relationship, the engineers also casually take on SSO and reporting requirements. At expiry, both sides feel the other didn't fulfill their commitments, yet neither can find which email defined the scope, who had authority to accept, or whether verbal approval in a demo meant ready for production.

AI Willingness-to-Pay Interviews are used to screen for real problems and commitments, and AI Concierge Pilots validate the value of manual delivery. This article starts from the point where both sides have already chosen to collaborate and governs the bilateral fulfillment of the Design Partner engagement; it doesn't repackage partnership eligibility as a research conclusion, nor promise that any pilot will inevitably become a paid contract.

charter.v1 Constrains Both Sides

Publish an immutable founder.designPartnerCharter.v1 that binds both parties' legal/business entities, authorized contacts, target problems, explicit in-scope and out-of-scope, start and expiry instants, meeting cadence, data classification, environments, exit handling, and a set of stable commitment IDs. Each commitment must specify owner, dueAt, input dependencies, completion evidence, acceptance role, service level, and the consequences of non-completion; "cooperate actively" and "go live as soon as possible" are unverifiable and cannot enter the formal charter.

schema: founder.designPartnerCharter.v1
charterId: dp-acme-support@3
startsAt: 2026-08-03T00:00:00Z
expiresAt: 2026-09-28T00:00:00Z
scope: [ticket-summary, reviewer-correction-export]
outOfScope: [auto-send, production-write, custom-sso]
commitments:
  - id: partner-sample-02
    owner: partner:data-steward
    dueAt: 2026-08-07T17:00:00-04:00
    evidence: approved-dataset-manifest@1
  - id: founder-sandbox-04
    owner: vendor:product-owner
    evidence: sandbox-release-receipt@2

RFC 8174 notes that normative words like MUST and SHOULD only carry their corresponding meanings when explicitly adopted. The charter should separate hard prerequisites, best-effort obligations, and exploratory hypotheses: when an approved sample hasn't been provided, the team MUST pause real-data runs; a single missed review may just be a SHOULD-level rescheduling. Times use RFC 3339 instants with offsets, and record who is responsible for confirming local holidays, to avoid each side interpreting "end of week six" differently.

Data usage separately references versioned boundaries: fields, purpose, region, retention period, permitted personnel, model vendors, and deletion receipts. A partner ad-hoc sending more production records cannot automatically widen the license. AI App Data Privacy Compliance handles the legal basis and data-subject rights; the charter only consumes its approved generation. When approval is unknown, it enters DATA_BLOCKED rather than using first and backfilling documents later.

Only Bilateral Sign-off Enters ACTIVE

The charter state machine is DRAFT -> MUTUAL_REVIEW -> READY_TO_ACTIVATE -> ACTIVE; missing an authorized entity enters AUTHORITY_BLOCKED, missing required data enters DATA_BLOCKED, and an overdue key commitment enters COMMITMENT_BLOCKED. The sole activation acceptance point is both parties' authorized persons signing a bilateralActivationReceipt.v1 against the same charter digest, and using CAS to advance the current generation to ACTIVE. Meetings being created, a Slack group being joined, a one-sided signature, or the first document being uploaded do not count as acceptance.

Each fulfillment produces a commitmentEvidence.v1 that binds charter, commitment, artifact digest, producing activity, actor, time, and verifier conclusion. The W3C PROV-O Entity, Activity, and Agent relationships can describe who generated a sample in which activity and which acceptance result derived from which version; adopters must lock down their own profile and required fields, not just save a "done" screenshot. Evidence conclusions are divided into SUBMITTED, VERIFIED, REJECTED, and SUPERSEDED; only a receipt from the designated verifier satisfies the commitment.

New requirements during the collaboration first take shape as a scopeChange.v1, listing the goal, effort, replaced commitments, data changes, expiry impact, and both parties' decision. After approval, a new charter generation is published; old tasks continue to bind to the old version or are explicitly canceled, and you can't retroactively apply an in-place-edited scope to already-completed work. Whether a feature is worth long-term investment is still judged by the AI Product Kill / Pivot Criteria and the AI Feature Evidence Scorecard; the Partner title itself is not a priority exemption.

Fourteen days before expiry it enters EXPIRING, allowing only RENEW_PROPOSED, COMPLETION_REVIEW, or EARLY_EXIT. Renewal is a new bilateral acceptance and must not auto-extend; if the goals are complete and the evidence is complete it enters COMPLETED, otherwise it enters EXPIRED_INCOMPLETE with the specific unfulfilled items. The closing process revokes environment access, stops new data ingestion, executes the retention/deletion policy, and delivers the artifacts both parties agreed on. Restarting the collaboration later creates a new charter lineage rather than flipping an expired version back to ACTIVE.

Deliberately Invalidate Collaboration Assumptions

Drills inject: the champion leaving, the signer lacking organizational authority, the two sides signing different digests, an old link being replayed, the sample arriving late with a changed schema, personal data exceeding the approved fields, review evidence coming from the wrong environment, the same commitment receiving conflicting conclusions, the customer requesting out-of-scope production writes, and tasks initiated before expiresAt but executed only after expiry. The system should reject mis-generation activation, converge permission and expiry CAS races to a single winner, and retain pending evidence rather than auto-judging completion.

Quantitative gates require that 100% of ACTIVE charters have a bilateral authorization receipt, an explicit expiresAt, in/out scope, and a data generation; 100% of commitments have a single owner, dueAt, evidence type, and verifier; the number of out-of-scope work items entering execution is 0; unapproved data being processed is 0; old-digest replay acceptance is 0. Weekly commitment status attribution rate is 100%; a key overdue item enters BLOCKED or gets a new-version approval within one business day; successful calls of new permissions after expiry are 0; when evidence is incomplete, the completion rate should be lowered rather than marked green.

On rollout, first shadow-map two existing Partners' collaboration documents to the charter without changing contracts or tool permissions; after one full cycle, only let new commitments drive state via receipts, then bind 20% of sandbox access to the charter generation. The old task board stays as a read-only fallback, with daily reconciliation of owner, deadline, and artifact. If a false block, an authority-mapping error, or evidence loss occurs, stop new activations and switch the collaboration alias back to a manual process while bumping the access revocation generation; historical receipts are not deleted. Only after two consecutive expiry/renewal drills pass are the old spreadsheets and permanent shared invitations retired.