Design Partner Pilot Pack

Why this page exists. SecurityRecipes already has the artifacts a serious reviewer wants to inspect. The next step is proving that those artifacts can run inside a customer pilot, produce telemetry, validate a hosted-ready proof path, and support a credible hosted MCP business.

Rechecked source anchors against the public MCP specification 2026-07-28 on August 21, 2026.

SecurityRecipes is positioned as The Secure Context Layer for Agentic AI. That claim becomes materially more valuable when a design partner can answer four questions quickly:

  • Which agent workflow are we piloting?
  • Which private context and MCP controls are in scope?
  • Which telemetry proves security and operational impact?
  • Which hosted-ready deployment path is this pilot validating?

The Design Partner Pilot Pack turns those questions into a generated artifact. It does not claim repeatable adoption proof exists yet. It defines the motion required to prove it.

What was added

  • data/assurance/design-partner-pilot-profile.json - source-backed pilot profile for reviewer segments, phases, telemetry, success metrics, hosted-ready proof paths, scope guardrails, diligence questions, and risk gates.
  • data/evidence/design-partner-pilot-pack.json - generated pack with source-pack hashes, readiness score, phase gates, readiness proof states, telemetry requirements, and diligence answers.
  • recipes_design_partner_pilot_pack - MCP tool for the full pack, a reviewer segment, pilot phase, hosted-readiness path, metric, diligence question, or pilot risk.

Workflow at a glance

Design Partner Pilot Pack workflow

Define a bounded design-partner pilot with baseline, controls, telemetry, success measures, stop signals, ownership, and renewal evidence.

trust-and-adoption

  1. Signal

    Choose the pilot workflow

    Select partner, owner, use case, repository/system, cohort, finding class, agent, data, tools, duration, and exclusions.

  2. Scope

    Establish baseline and controls

    Record current outcomes and bind context, identity, policy, approvals, telemetry, receipts, review, incident, and rollback.

  3. Decision

    Set success and stop criteria

    Define quality, speed, reviewer, safety, reliability, adoption, proof, escalation, and kill thresholds before launch.

  4. Action

    Operate the guarded pilot

    Run the bounded cohort, collect attributable events, review exceptions, contain incidents, and avoid silent scope expansion.

  5. Proof

    Decide the next stage

    Compare outcomes with baseline and choose expand, extend, tune, narrow, stop, or renew with owners and evidence.

Decision gate

Did the pilot meet declared safety, quality, reviewer, reliability, and value thresholds with trustworthy evidence?

Proceed

Approve one bounded expansion or renewal with maintained controls.

Hold or stop

Tune, narrow, pause, or stop when evidence or kill signals fail.

Evidence to retain

  • pilot charter and baseline
  • runtime/outcome measurements
  • stage decision and rationale

Expected outputs

  • design-partner pilot pack
  • expansion/renewal plan
  • pause/stop record

What the pack contains

Section Purpose
pilot_summary Readiness score, decision, source-pack readiness, phase count, readiness gate count, metric count, and failure count.
buyer_segments Frontier model lab, AI platform vendor, security platform vendor, and regulated enterprise views.
pilot_phases Qualify, bind private context, run read-only MCP, govern controlled actions, and prove the renewal case.
success_metrics Receipt completeness, context hash coverage, MCP decision coverage, reviewer time saved, automation success, safe holds, replay, private context, and renewal intent.
hosted_readiness_gates Hosted MCP policy, private context registry, connector drift, run-receipt vault, trust-center API, and continuous eval replay.
telemetry_requirements Metadata-first telemetry events and prohibited data classes.
risk_register Pilot risks with hold, deny, or kill decisions.

Why this is review-ready

The site already has open knowledge, generated evidence, and a production-oriented read-only MCP server. The missing enterprise proof is customer pull.

This pack makes that proof testable:

  • The open layer stays useful and forkable.
  • The pilot binds private context, telemetry, and customer evidence.
  • The hosted-ready proof path is explicit before implementation expands.
  • Synthetic ROI is labeled as assumption-based until customer telemetry replaces it.
  • The pilot can stop safely on token passthrough, approval bypass, unsafe model routing, raw secret capture, or connector drift.

That is the right path toward a credible trusted-source outcome: design partners first, hosted MCP controls second, renewal evidence third.

MCP examples

Inspect the full pilot pack:

recipes_design_partner_pilot_pack()

Inspect the regulated-enterprise reviewer view:

recipes_design_partner_pilot_pack(segment_id="regulated-enterprise")

Inspect the hosted MCP policy gate:

recipes_design_partner_pilot_pack(wedge_id="hosted-mcp-policy-plane")

Inspect the controlled-action phase:

recipes_design_partner_pilot_pack(phase_id="govern-controlled-actions")

Industry alignment

The profile is grounded in current primary sources:

See also