Self-Service Pilot

Evaluate one workflow without founder hand-holding

The first SMERC pilot should be narrow: one GitHub Actions workflow, MCP tool-call path, or cloud automation workflow, metadata-only inputs, observe mode, weekly reviewer labels, and a day-30 go/no-go decision. Existing approvals remain authoritative.

OBSERVE REVIEW REPORT

Customer-Owned Steps

What the company must provide

  • One selected repository or workflow family.
  • One security owner and one platform engineering owner.
  • One reviewer group willing to label sampled decisions weekly.
  • 10 to 25 plain-language sample action descriptions.
  • A metadata-only boundary with secrets, source code, customer records, private prompts, regulated payloads, and full incident logs excluded.
  • Day-30 decision criteria: stop, narrow, continue observe, or move to recommend mode.

30-Minute Path

Start here

  1. Read the CISO review and GitHub Actions pilot pages.
  2. Complete the customer intake packet with metadata-only workflow details.
  3. Run the intake checker and pilot readiness checker.
  4. Install observe-mode scoring for one GitHub Actions workflow.
  5. Collect `smerc-decision.json` artifacts.
  6. Review sampled decisions weekly.
  7. Generate the pilot evidence package at day 30.

What SMERC Provides

Self-service artifacts

  • Recoverability engine and REST API option.
  • GitHub Actions observe-mode examples.
  • Self-Service Pilot Connector for mixed action-language, MCP tool-call, and cloud automation examples.
  • Customer intake checker and pilot readiness checker.
  • Decision artifacts, reason codes, and recommended controls.
  • Pilot review metrics and evidence summary generator.
  • External benchmark context, including ILION-Bench v2 and Microsoft-style security replay.

Boundary

What this does not prove

Self-service materials reduce explanation burden. They do not prove demand, product-market fit, production safety, incident reduction, compliance, customer willingness to pay, or approval for enforcement.