Outcomes and shadow learning

Canvass records outcomes through versioned Temporal commands. Touch response, account relationship, and sales opportunity are separate state machines so a delivery event cannot silently become a sales-stage claim.

Versioned states

Corrections reference the exact prior transition and record actor, source, reason, and gtm-outcome-state-v1. Duplicate, conflicting, cross-account, and invalid transitions fail closed. These mutations use gtmActionWorkflowV2; they never write directly from an API route.

The authenticated API exposes three explicit durable commands:

POST /gtm/outcomes/v2
POST /gtm/outcomes/v2/correct
POST /gtm/opportunities/v2/transition

For example, a manual opportunity transition supplies its current state and an idempotent transition ID. The server derives source: manual, the actor from the session, the accepted state-model version, and forces the V2 Temporal route:

{
	"organizationId": "org_123",
	"commandId": "01J...",
	"transition": {
		"transitionId": "01J...",
		"companyId": "company_123",
		"fromState": "none",
		"toState": "qualified",
		"occurredAt": "2026-07-13T20:00:00.000Z"
	}
}

Immutable cohort attribution

Each new touch snapshots signal subtype, service-play and offer versions, normalized buyer function, outreach play, prompt version, proof version, and scoring-policy version. Lakebase migration 11 adds the immutable snapshot additively; historical rows retain an explicit legacy fallback so an older draining worker remains write-compatible during rollout.

Shadow reports group those snapshots, count attributed positive outcomes, and compute a Beta-smoothed rate. Dry-run touches are excluded. Reports can suggest what deserves investigation, but cannot select a contact, score, offer, proof, or copy variant.

const report = await computeShadowCohortReport(store);
// Reporting only. There is intentionally no production apply method.

Learning safety

gtm-learning-policy-v1 is fail-closed: mode is shadow_only, production activation is false, and environment variables cannot enable it. Production drafting stays pinned to the accepted control variant. adjustWeights may emit a shadow report, but may not persist weights that affect judging.

A future activation requires a separate accepted decision with calibration thresholds, minimum samples, rollout/rollback rules, and isolation tests.

Next: Replies, Evidence and scoring, and Databricks analytics.

Prepare a company-quality comparison

Engineering can check a frozen benchmark before scoring reviewed outputs:

pnpm --silent --filter @repo/gtm company-quality:preflight -- /private/packet.json /private/metadata.json > /private/preflight.json

Run this from the repository checkout. The offline command checks submitted owner-evidence references, two selected offers, contrasting-company and holdout coverage, fixed samples, negative controls and recorded reviewer calibration. Missing evidence produces an explicit issue. It does not call a model or provider. Keep source material, answer keys and reviewer evidence in authorized private storage.

A complete_metadata result means the submitted metadata is complete and consistent under these checks. The custodian must still verify private sources, approvals, reviewer independence and recorded resolutions. The report does not accept company quality or authorize launch. Score reviewed outputs separately with company-quality:score; usability and commercial results require their own evidence.

The repository's docs/testing/gtm-company-quality-protocol-v1.md documents the schema, packet hash, exit codes and remaining acceptance work. TechFabric's proposed two-offer answer key and reviewer calibration remain unconfirmed; passing this command with synthetic fixtures does not resolve them.