Pilot Intake

Test SMERC on your own workflow without sharing secrets.

Submit 5 to 25 metadata-only action examples from one workflow. SMERC can compare your current allow, block, review, or unknown posture against recoverability-aware runtime posture and produce a pilot intake report.

Boundary

Do not submit passwords, API keys, tokens, wallet keys, customer records, raw production logs, regulated payloads, or source-code dumps. Use safe metadata only.

01 Describe

Provide workflow type, current control model, and 5 to 25 action examples using safe metadata.

02 Compare

SMERC compares current posture against hard gates, recoverability scoring, routing, and evidence records.

03 Decide

The output shows whether a shadow-mode pilot is justified and what workflow should be tested first.

After You Submit

The first response is a bounded evaluation, not an integration request.

SMERC intake is intentionally narrow. The goal is to decide whether the workflow deserves a shadow-mode pilot while preserving your existing controls.

Review Metadata only

The examples are checked for safe boundaries and converted into the SMERC pilot-intake format.

Generate Pilot intake report

The report compares current controls with SMERC posture, reason codes, controls, Governance Routing Workbench routes, and ledger evidence.

Recommend Next posture

The outcome is one of three paths: no pilot, technical follow-up, or one workflow in shadow mode.

Preserve No production authority

SMERC does not request production credentials, enforcement authority, or replacement of existing IAM, policy, CI/CD, SIEM, GRC, or approval controls.

What You Get

A concrete report, not a sales presentation.

The intake process is designed to answer one commercial question: does recoverability scoring reveal governance differences your current controls miss?

Compare Current controls versus SMERC

A table showing current `ALLOW`, `BLOCK`, `REVIEW`, or `UNKNOWN` posture beside SMERC posture.

Rank Highest exposure actions

Actions are ranked by irreversible exposure, reversible capacity, rollback difficulty, and impact scope.

Explain Reason codes and controls

The report lists why SMERC changed or preserved posture and what controls would reduce risk.

Judge Pilot fit recommendation

The output states whether a narrow shadow-mode pilot is worth running and which workflow is best.

Best First Workflows

  • GitHub Actions or deployment workflows where AI or automation can ship code.
  • MCP tool-call paths where agents can read, write, delete, send, or mutate data.
  • Cloud administration where automation can alter IAM, networking, compute, storage, or Kubernetes state.
  • Security response where automated remediation can quarantine, revoke, isolate, or delete.
  • Financial operations where systems can transfer funds, issue refunds, settle transactions, or modify treasury posture.

Useful Metadata

  • Action description, actor, tool or workflow, environment, and current control outcome.
  • Reversibility, containment strength, rollback latency, evidence validity, and anomaly pressure.
  • Possible consequence, rollback path, current control reason, and likely human reviewer role.
  • Whether the action changes permissions, sends data externally, moves money, deletes data, or deploys infrastructure.

Submit Metadata-Only Examples

Request a SMERC pilot intake review.

Use this form for safe workflow metadata only. For technical teams that prefer local execution, use the GitHub JSON template and report generator instead.

Run It Yourself From GitHub

Technical reviewers can run the same path locally or inside GitHub Actions. The public repository includes a JSON intake template, Python report generator, tests, and a sample Markdown report.