Imported from kavins06/AI-OPERATING-PARTNER-MODEL (plugins/ai-operating-partner-model/skills/ai-operating-partner-engagement/SKILL.md). Install upstream with npx skills add kavins06/AI-OPERATING-PARTNER-MODEL --skill ai-operating-partner-engagement. Copyright stays with the author.

AI Operating Partner Engagement

Core Rule

Run the engagement as a structured, evidence-based pipeline. Use AI for heavy interviewing, extraction, synthesis, drafting, and scoring. Use the human operating partner for scope, judgment, prioritization, client trust, and final recommendations. Use the client for truth, examples, approvals, and ownership decisions.

Batch client participation into five touchpoints: strategy, workflow interview, evidence/data, governance validation, and decision/handoff. The full Step 0-18 method still runs internally. Reduce client burden by batching inputs and confirmations, not by shrinking workflow interviews, system/data discovery, truth-production mapping, governance validation, risk review, readiness scoring, or handoff rigor.

Use enterprise AI deployment evidence as a calibration layer. Treat workflow redesign, process documentation, data access, knowledge capture, change management, security review, and executive sponsorship as core implementation work. Do not overfocus on model choice when the durable advantage is usually workflow, proprietary data, guidance, evals, controls, orchestration, and model abstraction.

Never assume a clean source of truth exists. Discover how business truth is currently produced: official source, de facto trusted source, exports, formulas, spreadsheets/macros, manual adjustments, reconciliations, expert judgment, ownership, reproducibility, auditability, and AI-safe usage. Treat Excel macros, shadow trackers, manual reports, recurring reconciliations, and expert memory as structured organizational intelligence assets. Fragile truth must become a readiness blocker unless the proposed AI behavior is limited to safe actions such as summarize, compare, flag uncertainty, draft clarification questions, or escalate.

The engagement is a pre-build organizational intelligence, use-case selection, adoption, and implementation-blueprint engagement. It has 18 operating steps plus a Step 0 engagement-tiering frame. The current method does not add more steps; it hardens the system with tier matrices, schemas, protocols, rubrics, hard gates, packet contracts, lifecycle variants, halt taxonomy, and handoff rules. Do not build client agents, tools, connectors, MCP servers, live integrations, normalization pipelines, email ingestion, write-back automation, or production tools during this engagement. Implementation starts only after Step 18 is complete, the lifecycle and decision packet are approved, the method-to-build handoff is accepted, and the client starts a separate build phase.

No broad live company data access is required for early discovery. Start with executive terrain, role interviews, and silent evidence need logs. Request planning evidence only after the interview batch. Planning evidence can include redacted reports, screenshots, walkthroughs, sample exports, schema or field lists, API/vendor documentation, access-control screenshots, architecture notes, and data dictionaries when tied to a specific workflow object.

Do not request passwords, employee credentials, unrestricted production access, broad data-room access, all-email ingestion, unapproved API tokens, write access, or bulk unredacted data during the engagement. If live access, future tools, MCPs, connectors, normalization pipelines, or credentials are needed, Steps 14-18 should define the future implementation request package, not execute it. Treat MCP as one possible implementation pattern, not as the methodology's canonical platform assumption.

Cheap offline proof points are allowed inside the pre-build boundary only when they use approved redacted, synthetic, or historical examples and do not require live credentials, production integrations, write-back, deployment, or unapproved data movement. Treat them as evidence for guidance/eval/readiness, not as implementation.

This skill orchestrates the supporting skills and engagement gates. Step 8's controlled validation and object-driven governance resolution is a step in the engagement, not a separate skill; it is supported by data-governance-discovery below.

source-grounded-consulting
data-strategy-workshop
voice-interview-discovery
workflow-mapping
information-ecology-diagnostic
data-governance-discovery as an embedded helper for validation-stage source, owner, access, sensitivity, retention, and permission decisions
knowledge-map-capture
tacit-to-explicit-knowledge-capture
analytics-maturity-assessment
dashboard-kpi-design
data-monetization-canvas
warehouse-lakehouse-blueprint
privacy-security-risk-register
zero-trust-agent-controls
ai-agent-readiness-assessment
managed-agent-lifecycle

Reference Platform

Codex is the reference runtime for this skill set. The methodology is platform-agnostic: schemas, contracts, rubrics, and protocols can run on any harness. Install scripts, skill packaging, and the inter-skill orchestration pattern assume Codex by default. Operators using a different harness should preserve the schemas, rubrics, and step-numbered artifacts and substitute equivalent mechanics for skill loading and orchestration.

Primary Umbrellas

The seven umbrellas below are the user-facing structure for the engagement. The 18 numbered steps are implementation mechanics under these umbrellas.

Frame And Hypothesize: Steps 0-2.
Discover Reality: Steps 3-5.
Build And Validate The Intelligence Layer: Steps 6-8.
Define AI Reasoning Requirements: Steps 9-10.
Prove Measurement And Value: Steps 11-12.
Shape The Future Solution: Steps 13-15.
Decide And Govern: Steps 16-18.

Client Touchpoint Architecture

Use these five bundles as the client-facing operating cadence. They do not replace the Step 0-18 sequence.

Client bundle	Locks by	Client-facing content
Strategy bundle	End Step 2	Scope, goals, constraints, decision rights, candidate terrain, org coverage, participant list, and success criteria.
Workflow interview bundle	End Step 4	Role interviews, workflow variation, systems and sources named in context, edge cases, source paths, truth-production chains, and adoption signals.
Evidence/data bundle	Request at Step 5; resolve by Step 8	One consolidated evidence request plus approved artifacts or substitutes: redacted examples, screenshots, walkthroughs, reports, schemas, field lists, formulas, macros, access matrices, architecture notes, vendor docs, and policies.
Governance validation bundle	End Step 8	Controlled validation of workflows, systems, sources, official/de facto truth, owners/stewards, access, sensitivity, retention, and permitted/prohibited AI actions.
Decision/handoff bundle	End Step 18	Value, solution shape, adoption design, technical blueprint, risk controls, readiness, implementation decision packet, lifecycle, and method-to-build handoff.

No drip requests: after the interview batch, Step 5 should produce one owner-grouped planning-evidence request with SLA, sensitivity, redaction, handling, escalation, and acceptable substitutes. Additional client asks should be limited to hard blockers, disputed material facts, targeted expert validation, IT/data/security feasibility confirmation, risk/control confirmation, or final approval.

After Step 8, use the validated baseline to run most Steps 9-18 as operating-partner and AI synthesis. Bring the client back for targeted validation and approval rather than a new broad discovery cycle.

Practical Engagement Flow

Set the engagement tier and vertical extension using the tier matrix: choose lite, standard, or deep; confirm whether regulated-domain templates apply; define scope controls, expected depth, and the pre-build/offline-proof boundary.
Start with executive opportunity terrain mapping: understand strategy, growth, operating context, leverage areas, trust boundaries, and who can explain the real work. Use triangulated nomination: sponsor names, org-chart sampling, and "who do people call when this breaks?" probes. Assess sponsor mechanics: weekly blocker removal, business/technical co-sponsorship, OKR or incentive linkage, permission-to-fail culture, and lessons from prior AI or automation attempts.
Synthesize terrain into discovery zones and an explicit candidate use-case shortlist. Each candidate must have a hypothesis, target users, workflow boundary, value hypothesis, truth/adoption/regulatory dependencies, current confidence, disqualification criteria, and event slots for discovery, economic, and readiness disqualification. Screen for success-pattern fit: real pain, clear workflow, measurable outcome, recoverable-error potential, user willingness, existing data/process foundation, and revenue, risk, efficiency, or new-capability value.
Use role-aware AI-led interviews across organizational layers with the current AI interviewer protocol: hosting, consent, recording, retention, redaction, no-live-upload, no-asserted-facts, correction handling, refusal fallback, async norms, and operating-partner intervention. Capture work episodes, decisions, edge cases, source access, truth production, tacit judgment, approvals, adoption realities, resistance-source mapping, and silent evidence needs.
Run variation mapping when triggers exist: fragmented, franchised, multi-region, independent-contractor, multi-system, multi-portfolio, seniority-driven, or local-practice variation. If skipped, record a single-canonical-workflow assertion with evidence and revisit triggers.
Consolidate evidence needs after interviews and create a curated planning-evidence follow-up request with SLA, escalation, and acceptable substitutes. Ask only for the smallest useful set of redacted examples, screenshots, walkthroughs, formulas, macro walkthroughs, sample exports, schema/field lists, vendor docs, data dictionaries, process docs, prior pilot postmortems, KPI reports, security review requirements, access matrices, shadow AI signals, or knowledge-base samples. Do not request build access or credentials. Treat this as the single consolidated evidence request unless a hard blocker or disputed material fact requires follow-up.
Generate the initial AI-native organizational workflow intelligence object aligned to the canonical object schema: structured roles, org context, actors, steps, decisions, edge cases, information objects, source access profiles, truth production profiles, sources, systems, approvals, variation patterns, evidence, confidence, unknowns, completeness checks, and enrichment routes.
Run the organizational intelligence diagnostic using the current blocker rubric: attach findings to workflow objects, separate symptoms from likely root causes, score confidence, identify automation blockers, classify each blocker as fatal-for-use-case, requires-remediation-before-build, acceptable-with-controls, or informational, and route accordingly. Score invisible cost drivers: process redesign, process documentation, data access, knowledge capture, change management, staff-function resistance, sponsor behavior, security review burden, and prior-failure learning.
Validate through controlled role-specific views and object-specific governance resolution, then generate the Organizational Intelligence Baseline data contract using the current baseline release contract. Step 8 explicitly loops back to Step 6 and Step 7 when validation changes material workflow objects, truth profiles, source access paths, or blocker classifications. The baseline is the structured data substrate for a separate client-facing product; it is not the full raw internal object and not a report. By the end of Step 8, the engagement should have the workflow-specific system, data, source, owner, access, and truth-production baseline needed to support Steps 9-18.
Produce the AI knowledge and guideline requirements map for decisions, exceptions, escalation paths, truth production chains, expertise gaps, adoption knowledge, and regulated-domain knowledge. This maps requirements; it does not write final rules yet.
Convert prioritized requirements into an AI guidance pack: canonical machine-readable guidance spec, readable view, behavioral evals, output-quality evals, regulated-domain evals where applicable, truth-production handling, explicit rules, examples, output contract, owners, update cadence, validation status, eval methodology, minimum counts, regression versioning, and drift/revalidation rules.
Produce measurement intelligence and AI-capability metric design. Classify existing metric trust and truth status, then define future AI success metrics, leading indicators, lagging indicators, override/error/drift signals, cost metrics, and kill criteria. Include quality, customer value, revenue, speed-to-market, backlog, redeployment, hiring avoided, adoption, and new-capability metrics where relevant.
Produce business value case and portfolio comparison. Model value, AI-side costs, assumptions, confidence, fragile-truth caveats, and compare surviving opportunities so only 1-N are advanced to solution shape. Include headcount outcome scenarios: reduction, hiring avoided, redeployment, acceleration, revenue growth, new product/service creation, risk reduction, and capability expansion without headcount change.
Produce solution shape and adoption design. Treat this as 13a solution shape and 13b adoption design under one step. Decide build/buy/leverage-vendor, agent topology, model-selection class, UX surface, retrieval/context shape, eval/observability shape, oversight model, end-user research, incentive alignment, opt-in vs mandate reality, training, rollout, and adoption-failure triggers. Oversight model must be escalation, approval, or collaboration with rationale tied to error tolerance, regulation, task complexity, and recoverability.
Produce the technical/vendor implementation blueprint from the selected solution shape: architecture, integration, runtime/orchestration, hosting/environment, MCP/tooling, email access, normalization, identity resolution, truth-rule extraction, future component contracts, sandbox/test strategy, credential/secrets approach, audit/logging, blocked paths, and build sequence. Prefer access-layer, retrieval, progressive quality, and model-abstraction design over waiting for perfect centralized data.
Create the risk and control model with regulated-domain risk templates where applicable. Tie named risks to controls and owners, including privacy, security, shadow AI, output quality, truth-production risk, Fair Housing/TCPA/RESPA/MLS/state-license risks for real estate, and similar named rules for other verticals. Treat security as enabling infrastructure when it unlocks sensitive-data use through minimization, scrubbing, isolation, audit trails, and approved patterns. If risk forces topology, behavior-level, UX, retrieval, model, or adoption change, loop back to Step 13.
Score AI-agent readiness with an implementation-grade readiness object for each surviving opportunity using the current hard-gate rubric: behavior-level readiness, dependencies, blockers, evidence confidence, minimum safe first behavior, prohibited behaviors, and Step 17 path. Include sponsor behavior, prior-failure learning, process documentation, resistance profile, recoverable-error fit, data access, model/orchestration maturity, security enablement, and lifecycle ownership. Hard gates override average scores. This is still pre-build and does not authorize implementation.
Produce a machine-readable implementation decision packet using the decision-packet contracts. It specifies build-ready brief, gap-remediation plan, governance/data readiness plan, knowledge capture plan, technical feasibility plan, risk/control plan, or do-not-automate recommendation, with confidence statement, conditional-revision triggers, and sponsor/technical/risk/remediation views. When multiple packet types apply to one workflow, produce a packet_set.
Produce a machine-readable managed lifecycle and adoption-change object using the lifecycle variant contracts. Define future validation, launch, monitoring, truth governance, feedback, incidents, revocation, guidance/source updates, access review, adoption/change management, improvement, expansion, retirement, remediation lifecycle, no-automation review cadence, and the method-to-build handoff contract. Include failure-learning capture, model/runtime switching review, KPI refresh, role-transition tracking, and evidence-based expansion/retirement decisions. When Step 17 produces a packet_set, produce a lifecycle_set.

Resource Map

Read these when needed:

references/engagement-sequence.md: full order, roles, and decision gates.
references/role-interview-prompts.md: adaptive AI interviewer prompts by org layer.
references/input-collection-checklist.md: what to collect and how to ask for it.
references/output-standards.md: deliverable standards and build-ready packet definition.

Step To Physical Filename Map

File numbers reflect legacy history; the Step column is authoritative. Use this table to find the right artifact for a given step.

Step	Physical filename(s)
Cross-step contracts	`assets/templates/halt-taxonomy.yaml`, `assets/templates/offline-proof-catalog.yaml`, `assets/schemas/canonical-object-schemas.yaml`
Step 0	`assets/templates/00-engagement-tiering.yaml`, `assets/templates/00-tier-matrix.yaml`, `assets/templates/vertical-extension.schema.yaml`, `assets/templates/regulated-domain-extension.yaml`, `assets/templates/regulated-domain-extension-real-estate.yaml`
Step 1	`assets/templates/01-executive-opportunity-terrain.md`, `assets/templates/01-org-structure-capture.csv`
Step 2	`assets/templates/02-opportunity-terrain-synthesis.md`, `assets/templates/02-candidate-use-case-shortlist.yaml`, `assets/templates/02-interview-coverage-matrix.csv`
Step 3	`assets/templates/03-ai-interviewer-protocol.md`, `assets/templates/03-ai-interviewer-system-prompt.md`, `assets/templates/03-role-interview-guide.md`, `assets/templates/03-edge-case-register.csv`, `assets/templates/03-interview-evidence-need-log.csv`, `assets/templates/03-source-access-register.csv`
Step 4	`assets/templates/04-variation-map.yaml`
Step 5	`assets/templates/04-artifact-follow-up-request.md`, `assets/templates/04-artifact-follow-up-request.csv`
Step 6	`assets/templates/05-ai-workflow-spec.yaml`
Step 7	`assets/templates/06-organizational-intelligence-diagnostic.yaml`, `assets/templates/06-blocker-classification-rubric.md`
Step 8	`assets/templates/07-source-inventory.csv`, `assets/templates/07-validation-event.yaml`, `assets/templates/07-organizational-intelligence-baseline.yaml`, `assets/templates/07-baseline-release-contract.yaml`, `assets/templates/07-controlled-validation-call-view.md`
Step 9	`assets/templates/08-knowledge-map.md`
Step 10	`assets/templates/09-ai-guidance-spec.yaml`, `assets/templates/09-ai-guidance-test-cases.yaml`, `assets/templates/09-ai-guidance-skill.md`
Step 11	`assets/templates/10-measurement-intelligence.yaml`, `assets/templates/10-kpi-dictionary.csv`
Step 12	`assets/templates/11-business-value-case.yaml`, `assets/templates/11-portfolio-comparison.yaml`
Step 13	`assets/templates/12-solution-shape.yaml`, `assets/templates/13-adoption-design.yaml`
Step 14	`assets/templates/12-technical-implementation-blueprint.yaml`
Step 15	`assets/templates/13-risk-control-model.yaml`, `assets/templates/13-risk-register.csv`
Step 16	`assets/templates/14-ai-agent-readiness-score.yaml`, `assets/templates/14-hard-gates-readiness-rubric.yaml`, `assets/templates/14-readiness-scorecard.csv`
Step 17	`assets/templates/15-implementation-decision-packet.yaml`, `assets/templates/15-implementation-decision-packet-set.yaml`, `assets/templates/15-decision-packet-contracts.yaml`, `assets/templates/15-build-ready-implementation-brief-view.md`
Step 18	`assets/templates/16-managed-lifecycle-object.yaml`, `assets/templates/16-lifecycle-set.yaml`, `assets/templates/16-lifecycle-variant-contracts.yaml`, `assets/templates/16-managed-lifecycle-sop-view.md`, `assets/templates/18-method-to-build-handoff-contract.md`

Use these templates:

assets/templates/TEMPLATE_INDEX.md
assets/templates/00-engagement-tiering.yaml
assets/templates/00-tier-matrix.yaml
assets/templates/regulated-domain-extension.yaml
assets/templates/vertical-extension.schema.yaml
assets/templates/regulated-domain-extension-real-estate.yaml
assets/templates/halt-taxonomy.yaml
assets/templates/offline-proof-catalog.yaml
assets/schemas/canonical-object-schemas.yaml
assets/templates/01-executive-opportunity-terrain.md
assets/templates/01-org-structure-capture.csv
assets/templates/02-opportunity-terrain-synthesis.md
assets/templates/02-candidate-use-case-shortlist.yaml
assets/templates/02-interview-coverage-matrix.csv
assets/templates/03-ai-interviewer-system-prompt.md
assets/templates/03-ai-interviewer-protocol.md
assets/templates/03-role-interview-guide.md
assets/templates/03-edge-case-register.csv
assets/templates/03-interview-evidence-need-log.csv
assets/templates/03-source-access-register.csv
assets/templates/04-variation-map.yaml
assets/templates/04-artifact-follow-up-request.md
assets/templates/04-artifact-follow-up-request.csv
assets/templates/05-ai-workflow-spec.yaml
assets/templates/06-organizational-intelligence-diagnostic.yaml
assets/templates/06-blocker-classification-rubric.md
assets/templates/07-source-inventory.csv
assets/templates/07-controlled-validation-call-view.md
assets/templates/07-validation-event.yaml
assets/templates/07-organizational-intelligence-baseline.yaml
assets/templates/07-baseline-release-contract.yaml
assets/templates/08-knowledge-map.md
assets/templates/09-ai-guidance-spec.yaml
assets/templates/09-ai-guidance-skill.md
assets/templates/09-ai-guidance-test-cases.yaml
assets/templates/10-measurement-intelligence.yaml
assets/templates/10-kpi-dictionary.csv
assets/templates/11-business-value-case.yaml
assets/templates/11-portfolio-comparison.yaml
assets/templates/12-solution-shape.yaml
assets/templates/12-technical-implementation-blueprint.yaml
assets/templates/13-adoption-design.yaml
assets/templates/13-risk-control-model.yaml
assets/templates/13-risk-register.csv
assets/templates/14-ai-agent-readiness-score.yaml
assets/templates/14-hard-gates-readiness-rubric.yaml
assets/templates/14-readiness-scorecard.csv
assets/templates/15-implementation-decision-packet.yaml
assets/templates/15-implementation-decision-packet-set.yaml
assets/templates/15-decision-packet-contracts.yaml
assets/templates/15-build-ready-implementation-brief-view.md
assets/templates/16-managed-lifecycle-object.yaml
assets/templates/16-lifecycle-set.yaml
assets/templates/16-lifecycle-variant-contracts.yaml
assets/templates/16-managed-lifecycle-sop-view.md
assets/templates/18-method-to-build-handoff-contract.md

Use scripts:

scripts/score_readiness.py
scripts/score_analytics_maturity.py
scripts/score_risk.py
scripts/transcript_extract.py

Output Modes

step numbering overrides older step references:

Step 0: engagement tiering and vertical extension.
Step 2: candidate use-case shortlist and disqualification criteria.
Step 4: variation mapping for fragmented operating models.
Step 11: measurement intelligence plus AI-capability metric design.
Step 12: business value case plus portfolio comparison.
Step 13: solution shape plus end-user adoption design.
Step 14: technical/vendor implementation blueprint.
Step 15: risk and control model.
Step 16: AI-agent readiness score.
Step 17: implementation decision packet.
Step 18: managed lifecycle and adoption-change object.

If the user asks to start an engagement, produce:

Engagement tiering recommendation: lite, standard, or deep.
Vertical extension recommendation and regulated-domain template need.
Client touchpoint plan: strategy, workflow interview, evidence/data, governance validation, and decision/handoff bundles with lock points.
Executive opportunity terrain request.
Sponsor mechanics request: blocker-removal cadence, business/technical co-sponsors, OKR or incentive linkage, permission-to-fail posture, and prior AI/automation attempts.
Opportunity terrain synthesis, discovery-zone sequencing plan, and candidate use-case shortlist.
Interview plan.
Variation-mapping plan, if the org is fragmented, franchised, multi-region, or independent-contractor driven.
Preliminary artifact request plan.
Timeline.
Roles and responsibilities.

If the user gives executive terrain notes, produce:

Strategic context summary.
Sponsor mechanics and prior-failure learning summary.
Full opportunity terrain map.
Candidate use-case shortlist with hypothesis, target user, workflow boundary, value hypothesis, trust dependencies, adoption dependencies, regulated-domain dependencies, confidence, and disqualification criteria.
Success-pattern fit screen per candidate: real pain, measurable outcome, recoverable-error fit, user willingness, existing foundation, sponsor strength, and revenue/risk/efficiency/new-capability potential.
Sequenced discovery tiers.
Rationale for sequencing.
Interview and artifact request plan.
Sponsor confirmation questions.

If the user gives transcripts or notes, produce:

Extracted work episodes.
Participation and sampling-bias notes.
Variation map if saturation against one canonical workflow is invalid.
Initial AI workflow specification.
Source and system map.
Information object and source access profiles.
Truth production map and truth production profiles.
Adoption, incentive, and end-user trust signals.
Resistance-source map across end users, managers, Legal, HR, risk, compliance, finance, IT/security, data owners, technical owners, and executives.
Operating strain and value signals.
Knowledge gaps.
Risk signals.
Regulated-domain signals where applicable.
Edge case register.
Silent evidence need log.
Interview quality score.
Cross-interview triangulation notes.
Follow-up questions.

If the user asks for a workflow map, produce the AI-native workflow specification as the canonical workflow artifact and optionally generate a human-readable view from it.

If the user gives an AI workflow specification, produce:

Organizational intelligence diagnostic.
Object-linked diagnostic findings.
Root-cause hypotheses.
Invisible-cost assessment: process redesign, documentation, data access, knowledge capture, change management, sponsor behavior, resistance, security review, and prior-failure learning.
Automation blockers.
Intervention routes.
Scale recommendation: downsized, standard, or upscaled.
Next enrichment steps.

If the user asks to validate a model, produce:

Role-specific validation views.
Object-specific governance resolution views.
Correction prompts.
Structured validation event.
Source inventory, source access profiles, and governance enrichment for relevant objects.
Official source, de facto trusted source, truth production, owner/steward, sensitive-field, retention, access, and permitted-AI-action decisions where available.
Confirmed, corrected, disputed, unknown, and not-reviewed objects.
Remaining unresolved items, limited to issues that could not be decided by the authorized resolver group.
Organizational Intelligence Baseline payload: graph nodes, graph edges, candidate AI portfolio, AI-fit boundaries, truth production registry, validation state, product-view contract, and downstream seeds for Steps 9-18.

If the user asks for Step 8, produce:

Controlled validation and governance resolution event.
Confirmed, corrected, disputed, unresolved, unknown, and not-reviewed critical objects.
Source access confirmations and unresolved access-path questions.
Truth production confirmations: official source, de facto trusted source, chain, embedded rules, manual adjustments, owner/knower, reproducibility, auditability, and AI-safe usage.
Governance decisions: owner/steward, sensitive fields, retention/export/handling constraints, permitted AI actions, and prohibited AI actions.
Back-edge decision: continue, update Step 6, re-score Step 7, update Step 2 shortlist, expand interviews/variation mapping, or pause.
Organizational Intelligence Baseline as the product data substrate: scope, identity/privacy policy, graph nodes, graph edges, candidate AI portfolio, AI-fit boundaries, validated intelligence summary, validation state, product-view contract, and downstream seeds for Steps 9-18.
Release status for client product views: ready, partial, or blocked, with required updates before release.

If the user gives interview outputs, edge case registers, or silent evidence need logs, produce:

Evidence need consolidation.
Curated planning-evidence follow-up request.
Data access posture.
Owner-grouped requests.
Source access path validation needs.
Truth production validation needs.
Redaction, access-scope, and retention/handling requirements.
Explicit note that credentials, live integration access, MCP builds, connector builds, normalization builds, and broad email access are out of scope until after Step 18 approval.

If the user asks whether to build, produce:

Implementation-grade readiness object.
Build/fix/do-not-automate decision.
Behavior-level readiness and minimum safe first behavior.
Hard gates, blockers, and required fixes.
Machine-readable implementation decision packet.
Machine-readable managed lifecycle object or remediation/no-automation lifecycle.
Confirmation that implementation begins only after Step 18 approval and separate implementation authorization.

If the user asks for Step 9, produce:

AI knowledge and guideline requirements map.
Decision-linked knowledge requirements.
Truth-production-linked knowledge requirements.
Adoption-linked and regulated-domain knowledge requirements.
Evidence and confidence for each requirement.
Likely expert/owner and reason they were inferred.
Where knowledge appears to live: policy, SOP, system, document, role, meeting, email, tracker, spreadsheet, macro, reconciliation habit, or expert memory.
Examples needed: good, bad, edge case.
AI guideline requirements: what future guidance must exist.
Gap/risk and next route: tacit capture, policy review, SOP needed, risk review, or no-agent-use-yet.
Targeted confirmation questions only for high-value, high-risk, or low-confidence items.

If the user asks for Step 10, produce:

AI guidance pack scoped to one workflow, decision, exception family, or future agent behavior.
Machine-readable guidance spec as the canonical artifact.
Markdown readable guide as a platform-agnostic view of the same guidance.
Behavioral evaluation cases and output-quality evaluation cases covering good, bad, edge, low-confidence, source-conflict, fragile-truth, regulated-domain, and escalation scenarios.
Required inputs, trusted sources, source hierarchy, and information object references.
Truth production handling: allowed statuses, fragile truth behaviors, confidence language, and escalation rules.
Explicit rules, tacit cues, examples, review criteria, escalation triggers, and forbidden behaviors.
Output contract: allowed format, required fields, confidence, citations/evidence references, and human-review flags.
Owner, update cadence, validation status, unresolved gaps, and implementation notes.
Confirmation that this is still pre-build guidance, not a deployed agent, MCP, connector, normalization pipeline, or live system integration.

If the user asks for Step 11, produce:

Measurement intelligence object scoped to the validated workflow, decisions, and candidate AI assists.
Decision-to-metric map: which decisions depend on which numbers and why.
Metric trust classification: trusted, conditionally trusted, disputed, untrusted, or unknown.
Trust evidence: official source, de facto trusted source, truth production chain, formula, grain, owner, steward, freshness, reproducibility, auditability, reconciliation status, quality checks, access boundary, and actual decision use.
KPI dictionary needs: metric definitions, thresholds, formulas, grains, refresh cadence, owners, quality checks, allowed filters, and drilldowns.
Report/dashboard reality: current reports used, shadow trackers, manual exports, stale dashboards, and conflicting views.
Truth production reality: macros, formulas, manual adjustments, recurring reconciliations, expert-memory rules, and fragile artifacts that produce final numbers or statuses.
Agent-safe metric usage: what future AI may calculate, cite, compare, summarize, flag, or must escalate.
AI-capability metric design: baseline, leading indicators, lagging indicators, override rate, error rate, drift signals, adoption metrics, cost metrics, and kill criteria.
Value metric breadth: quality, customer value, revenue conversion or retention, speed-to-market, backlog reduction, role redeployment, hiring avoided, staff-function approval latency, shadow AI reduction, and new capability creation where relevant.
Unresolved metric questions routed to Step 8 governance resolution, Step 14 architecture/normalization blueprint, Step 16 readiness scoring, or do-not-use-yet.
Confirmation that Step 11 does not build dashboards, pipelines, models, agents, MCPs, connectors, or live integrations.

If the user asks for Step 12, produce:

Business value case scoped to one workflow, opportunity, or candidate future AI assist.
Portfolio comparison across candidate opportunities.
AI-side cost modeling: model calls, tool calls, retrieval/indexing, observability, evals, maintenance, tuning, support, and change-management cost.
Value hypotheses by lens: internal efficiency, cycle time, rework/error reduction, decision quality, risk reduction, revenue protection/growth, customer/tenant/vendor experience, and reusable data product value.
Headcount and capacity scenarios: direct reduction, hiring avoided, redeployment, acceleration of backlog or roadmap, no-headcount-change capability expansion, revenue growth, and new product/service creation.
Evidence-linked baseline metrics from Step 11, using only trusted or conditionally trusted measurements unless the value case is explicitly about fixing measurement or truth infrastructure.
Truth production dependencies and whether fragile metrics are excluded from baseline evidence unless the case is explicitly about fixing measurement/truth infrastructure.
Assumptions, confidence, and sensitivity: conservative/base/upside where evidence supports ranges.
Value dependencies: source access, knowledge/guidance, measurement, governance, architecture, risk, and change-management prerequisites.
Client-confirmation needs: volumes, costs, decision priorities, acceptable assumptions, and leadership value preference.
Recommendation: carry forward to solution shape, fix measurement first, fix truth production first, fix governance/knowledge/adoption first, deprioritize, or do not pursue.
Confirmation that Step 12 is an economic and portfolio filter and does not authorize build work.

If the user asks for Step 13, produce:

Solution shape decision scoped to the surviving opportunity.
Build, buy, leverage-existing-vendor, hybrid, defer, or do-not-advance decision.
Agent topology: no-agent workflow, single assistant, workflow with LLM steps, tool-using agent, multi-agent system, or monitoring agent.
Model selection class: small/fast, frontier, private/open-weight, routed models, client-mandated, or unknown.
UX surface: existing CRM/system, email, chat, dashboard, mobile, browser extension, separate app, or workflow queue.
Oversight operating model: escalation, approval, or collaboration, with rationale tied to error tolerance, regulation, task complexity, recoverability, and expected productivity/value tradeoff.
Retrieval/context shape, source grounding, permission filtering, eval/observability shape, and offline proof-point recommendation.
End-user research, adoption feasibility, incentive alignment, opt-in vs mandate reality, training plan, rollout plan, support model, feedback channels, and adoption-failure triggers.
Confirmation that Step 13 decides solution/adoption shape only and does not build or integrate anything.

If the user asks for Step 14, produce:

Technical implementation blueprint scoped to the surviving opportunity, workflow, value case, and candidate future AI assists.
Implementation posture: technically feasible, feasible with conditions, blocked, or not worth blueprinting yet.
Systems and sources with business owner, technical owner, vendor owner, data needed, sensitivity, quality issues, source access profiles, and role in the workflow.
Access options: preferred path, fallback path, blocked paths, feasibility status, license/vendor/security constraints, sandbox availability, audit logging, and future access request.
Canonical entities and identity-resolution rules for matching records across systems.
Normalization requirements: source field, target field, rule, owner, quality check, blocker, and freshness need.
Truth production remediation: macro extraction, formula documentation, rule capture, semantic normalization, canonical entity design, reconciliation tests, owner assignment, governed replacement, or shadow artifact retirement.
Runtime/orchestration requirements: minimum safe runtime pattern, whether RAG is required, whether multi-agent design is justified, model capability needs, state/workflow/queue needs, human approval gates, retry/idempotency needs, and audit trace requirements.
Data access over perfection plan: how scattered, messy, unstructured, or incomplete data will be retrieved, transformed, validated, cited, escalated, and improved over time.
Model abstraction or multi-model routing plan where useful: routing by cost, latency, privacy, capability, task complexity, validation redundancy, and vendor flexibility.
Hosting/environment requirements: client cloud or mandated stack, identity provider, data residency, VPC/private networking, compute pattern, storage needs, queues, secrets manager, observability, vendor/security review, and preferred/fallback/blocked hosting patterns.
Future tool/MCP/connector contracts: purpose, input contract, output contract, allowed actions, prohibited actions, data touched, permission scope, human review, logging, and build phase.
Document and email scope: approved folders, labels, mailboxes, retention constraints, prohibited all-email access, and manual staging alternatives.
Test and validation plan: redacted examples, synthetic data, sample exports, linked Step 10 eval cases, sandbox needs, and success criteria.
Credential and secrets plan for future implementation: credential type, provisioning owner, storage, rotation, revocation, audit, and approval dependencies.
Build sequence with prerequisites, outputs, exit criteria, and do-not-build-yet boundary.
Open technical, security, vendor, data-owner, and business decisions with owners and blocking status.

If the user asks for Step 15, produce:

Risk and control model scoped to the opportunity, workflow, technical blueprint, future tools, data, outputs, and approval paths.
Input trace: workflow actions, edge cases, sensitive fields, source constraints, forbidden behaviors, metric trust, value/risk tolerance, access paths, future tool contracts, document/email scope, and credential/secrets plan.
Data classification matrix: sensitive fields or content classes, source, classification, handling rule, allowed AI use, prohibited AI use, retention/export constraints, and confirmation status.
Regulated-domain risk template where applicable, with named regulations and owner-confirmed controls.
Risk register with linked workflow object, system, source, truth production profile, tool, output, cause, impact, likelihood, severity, control, owner, verification needed, and residual risk.
Truth production risks: spreadsheet risk, key-person truth risk, undocumented transformation, auditability gap, and shadow-reporting drift.
Zero-trust control model covering identity, role/user scope, data access, record/field/document restrictions, tool permissions, output controls, approval gates, logging, monitoring, incident response, and revocation.
Shadow AI risk and control plan, including approved alternatives, policy gaps, training, monitoring signals, and escalation path.
Security-as-enabler patterns where relevant: PII scrubbing, data minimization, synthetic substitution, isolation/private networking, audit trails, contractual controls, and approved cloud/vendor patterns.
Tool-level permission matrix: allowed actions, prohibited actions, human approval requirements, logging requirements, and stop conditions per future tool/MCP/connector.
Output controls: allowed internal summaries/drafts, prohibited outputs, external-send approval, citation/evidence requirements, confidence requirements, and uncertainty language.
Stop conditions that block implementation until fixed.
Targeted confirmation questions for the smallest authorized owner group only.
Confirmation that Step 15 designs controls only and does not provision credentials, grant access, deploy monitoring, connect tools, or implement automations.

If the user asks for Step 16, produce:

AI-agent readiness object scoped to one candidate opportunity, workflow, proposed user group, and business outcome.
Source-input coverage from Steps 0-15, including missing or partial inputs.
Proposed first AI behavior level and accountable human owner.
Hard gates: use-case framing, business value, sponsor behavior, workflow clarity, process documentation, source access, data quality, truth production, regulated-domain, knowledge/guidance, measurement, solution shape, adoption/change, technical feasibility, model/orchestration, risk/control, security enablement, resistance profile, recoverable-error fit, human oversight, and lifecycle.
Gate status: pass, conditional, fail, blocked, or unknown, with evidence, confidence, owner, blocker flag, and required fix.
Dimension scores: use-case framing readiness, sponsor behavior, prior failure learning, business value, workflow clarity, process documentation, source access readiness, data quality, truth production readiness, knowledge/guidance readiness, measurement readiness, AI-capability metrics readiness, regulated-domain readiness, solution-shape readiness, architecture feasibility, model/orchestration readiness, risk/control readiness, security enablement, resistance profile, recoverable-error fit, adoption/change readiness, human oversight readiness, and change/lifecycle readiness.
Behavior-level readiness: read-only summary, draft-and-flag, recommendation support, human-approved action, and autonomous action.
Dependency map across systems/sources, truth production profiles, guidance packs, metrics, technical dependencies, future tools/MCPs/connectors, normalization, identity resolution, test data, credentials/secrets, logging, and controls.
Blockers with owner, required fix, linked gate, linked dimension, behavior levels blocked, and whether the blocker changes the Step 17 path.
Minimum safe first behavior with allowed actions, required inputs, human review, controls, tests, and explicit limitations.
Not-ready and prohibited behaviors with reasons and reconsideration conditions.
Readiness decision: ready for Step 17 build brief, fix gaps first, governance/data readiness first, knowledge capture first, adoption first, technical feasibility first, risk/control first, deprioritize, do not automate yet, or discovery incomplete.
Recommended Step 17 path: build-ready implementation brief, gap remediation plan, governance/data readiness plan, knowledge capture plan, adoption plan, technical feasibility plan, risk/control plan, or do-not-automate recommendation.
Confirmation that Step 16 does not start agent build, MCP/connector build, normalization build, credential requests, live access, or implementation.

If the user asks for Step 17, produce:

Machine-readable implementation decision packet as the canonical artifact, preferably YAML or JSON. If multiple packet types apply to the same workflow, produce a packet_set.
Packet type: build-ready implementation brief, gap-remediation plan, governance/data readiness plan, knowledge capture plan, technical feasibility plan, risk/control plan, or do-not-automate recommendation.
Source-input trace from Steps 0-16, especially Step 16 readiness object, Step 14 technical blueprint, Step 15 risk/control model, Step 13 solution/adoption design, Step 10 guidance pack, Step 11 measurement intelligence, Step 12 value case, Step 6 workflow intelligence object, and Step 8 governance/source-access/truth-production decisions.
Decision summary: recommended path, rationale, minimum safe behavior level, client decision needed, and implementation approval boundary.
Recommendation confidence and conditional-revision triggers.
Audience views generated from the same packet: sponsor view, business owner view, IT/data/security view, future build team view, and remediation-owner view.
Business case summary with trusted or conditionally trusted baseline metrics, value range, dependencies, and risks.
First-build scope if build-ready: agent/workflow name, behavior level, users, included/excluded workflow steps, included/excluded roles, included/excluded edge cases, phase-1 success definition, and explicit non-goals.
Behavior contract: allowed actions, prohibited actions, approval gates, output contract, and failure behavior.
Systems and sources: owners, official source status, de facto trusted source status, truth status, data needed, required fields, sensitive fields, source access profiles, truth production profiles, future access path, fallback path, prohibited paths, freshness, data quality, retention/export constraints, and readiness status.
Truth production readiness and remediation: truth profiles, status, reproducibility, auditability, safe AI usage, required fixes, and whether the packet must become a remediation plan.
Runtime design requirements: selected future pattern as a requirement, minimum viable pattern, model capability requirements, RAG/retrieval requirements, orchestration/state needs, multi-agent rationale if any, and explicit overengineering guardrails.
Hosting/environment requirements: preferred/fallback/blocked hosting patterns, client cloud/identity/network/security constraints, compute and storage requirements, secrets, observability, and vendor/security review needs.
Future component contracts: tools, MCPs, connectors, retrieval indexes, normalization jobs, workflow queues, or eval runners, with input contract, output contract, allowed/prohibited actions, data touched, permission scope, human review, logging, failure behavior, and dependencies.
Normalization and truth remediation plan: canonical entities, mappings, identity-resolution rules, quality checks, macro/formula/rule extraction, reconciliation tests, owner assignment, blockers, and freshness requirements.
Guidance and eval package: linked guidance packs, rules, examples, eval cases, expected behavior, pass criteria, and exit criteria.
Risk/control package: data access controls, tool permissions, output controls, approval gates, audit logs, monitoring, incident response, and revocation.
Future access request package for after Step 18 approval: system/source, purpose, permission scope, prohibited permissions, provisioning owner, approval dependencies, credential/secrets handling, rotation, revocation, audit logging, and test/sandbox preference.
Build sequence: offline prototype, sandbox integration, limited pilot, controlled expansion if appropriate, with prerequisites, inputs, outputs, tests, exit criteria, and stop conditions.
Owner matrix: business owner, day-to-day owner, technical owner, data owner, security owner, risk/compliance owner, future build owner, and approvers.
Remediation plan if not build-ready: reason not ready, required fixes, linked readiness gate, owner, evidence needed, completion criteria, dependencies, reassessment trigger, and return to Step 16.
Do-not-automate recommendation if applicable: reasons, unacceptable risks, alternative recommendation, and revisit conditions.
Stop boundary confirming that Step 17 does not start agent build, MCP/connector build, normalization build, credential requests, live access, email ingestion, or implementation.

If the user asks for Step 18, produce:

Machine-readable managed lifecycle object as the canonical artifact, preferably YAML or JSON. If Step 17 produced a packet_set, produce a lifecycle_set.
Lifecycle path: managed agent lifecycle, remediation lifecycle, or no-automation review cadence.
Source-input trace from Step 17 packet, Step 16 readiness object, Step 15 risk/control model, Step 14 technical blueprint, Step 13 solution/adoption design, Step 12 value/portfolio case, Step 11 measurement intelligence, Step 10 guidance/eval pack, and linked workflow/source/truth governance objects.
Operating status and approval boundary confirming this is still pre-build and no agent is deployed, monitored, connected, or operated during the engagement.
Lifecycle scope: future agent/workflow name, opportunity, business outcome, authorized behavior level, non-authorized behavior levels, target user groups, environments, and scope exclusions.
Owner model: business owner, day-to-day owner, technical owner, data owner, security owner, risk/compliance owner, support owner, guidance update owner, measurement owner, source freshness owner, incident owner, revocation owner, future build owner, sponsor, approval forum, and responsibility matrix.
Future lifecycle stages: implementation approval, offline validation, sandbox integration, limited pilot, controlled rollout, monitored operation, and expansion/retirement review, each with entry criteria, exit criteria, approvals, and stop conditions.
Launch gates: evals passed, controls verified, audit logging ready, human review workflow confirmed, revocation ready, and support model ready.
Validation plan: eval suites, redacted/synthetic test data, source grounding, edge cases, permission boundaries, output quality, human review, failure behavior, and pre-pilot exit criteria.
Monitoring plan: quality metrics, business metrics, risk metrics, technical metrics, source freshness checks, cost/usage metrics, owners, thresholds, alerts, and cadence.
KPI refresh and value-realization plan: baseline refresh, target review, value-capture owner, headcount/capacity outcome tracking, and new-capability evidence.
Truth governance: source drift checks, rule-change approval, reconciliation cadence, owner review, and retirement of shadow artifacts.
Feedback and correction loop: channels, correction categories, severity routing, backlog owner, and review cadence.
Failure-learning loop: prior failed attempts, pilot misses, root-cause capture, sponsor review, and changes to guidance, data, controls, adoption, or architecture.
Adoption and change management: training, incentive alignment, opt-in/mandate limits, workflow sunsetting, feedback channels, adoption metrics, and adoption-failure triggers.
Change management: guidance updates, source changes, tool changes, model/runtime changes, required revalidation triggers, and versioning policy.
Model/runtime switching review: cadence and triggers for changing model, routing, inference provider, orchestration framework, or open/private model posture.
Access review and revocation: review cadence, scope, revocation triggers, emergency pause process, restoration conditions, and response times.
Incident response: owner, severity levels, triggers, escalation path, evidence preservation, notification expectations, and post-incident review.
Governance cadence: pilot review, steady-state review, and executive review attendees, agenda, and decision rights.
Expansion criteria: eligible expansion types, required evidence, owner approval, Step 16 reassessment, and Step 17 packet update.
Retirement criteria: low usage, high correction rate, source replacement, no measurable value, unacceptable risk, retirement owner, revocation, retention/deletion, and documentation update.
Remediation lifecycle if not build-ready: linked fixes, owner, review cadence, evidence required, return to Step 16, and stop-if-not-resolved conditions.
No-automation review cadence if do-not-automate: reason, alternative operating recommendation, revisit conditions, owner, and cadence.
Final approval: Step 18 approval status, approvers, notes, implementation authorization, and conditions before implementation.
Stop boundary confirming no build, no live access, no credentials, no MCP/connector build, no normalization pipeline build, no email ingestion, and no deployed or operated agent during the engagement.

Quality Bar

Do not initiate or recommend initiating implementation until every precondition below is met. Each precondition is a hard requirement, not an aspiration.

The engagement tier is selected and sponsor-confirmed (lite, standard, or deep), with vertical-extension applicability resolved.
Candidate use cases are explicitly framed and either disqualified at the appropriate step or advanced as alive opportunities.
Material workflow variation is mapped at Step 4, or the single-canonical-workflow assertion has evidence and revisit triggers.
The AI workflow specification conforms to the canonical object schema, including required nested objects with evidence_refs and confidence.
Material sources, systems, and owners are known or routed; source access profiles exist for material information objects.
Truth production profiles are mapped for material numbers, statuses, reports, and decision inputs, and each is classified by truth_status and routed accordingly.
Regulated-domain obligations are identified, the applicable extensions are loaded, and the client_must_supply inputs (where required) are in place.
AI knowledge and guideline requirements are mapped and tacit knowledge gaps are named with capture routes.
Step 10 guidance packs and eval suites are structured per the canonical guidance contract, with methodology, minimum counts, regression versioning, and drift rules in place.
Existing measurements are trust-classified (authoritative, conditionally_reliable, shadow_derived, manually_adjusted, person_dependent, disputed, missing, not_reproducible, unknown) and AI-capability metrics including success, override, error, drift, adoption, cost, and kill criteria are designed.
A credible business value case exists and a portfolio decision selects the 1..N opportunities to advance.
Solution shape and end-user adoption design are explicit (13a and 13b) and survive Step 15 risk loop.
Fragile truth is either remediated or limited to safe AI behavior per the truth-production gate's behavior-level rules.
Sensitive data, approval gates, output controls, and revocation paths are designed.
The technical/vendor blueprint documents access paths, future component contracts, normalization, runtime, hosting, secrets, and build sequence without live access.
Risk and zero-trust controls are defined, including regulated-domain risks, named owners, stop conditions, and Step 15-to-Step 13 loop status.
Readiness is scored using the hard-gate rubric; hard gates pass or are conditional only for explicitly pre-build/pilot conditions; behavior-level readiness is named.
The Step 17 implementation decision packet (or packet_set) matches its packet contract(s) per type.
The Step 18 managed lifecycle (or lifecycle_set) matches its variant contract(s) and includes the method-to-build handoff contract.
The method-to-build handoff is approved by sponsor, owner forum, and required security/risk/legal/data owners.

ai-operating-partner-engagement

About