Customer Onboarding

Starter Scaffold for payload construction

Use this guide when you want a simple customer-facing request shape without hand-building the fixed 38-slot payload. The default starter now uses SCOP Method 2 and the runtime adapter compiles metrics into the internal fixed-slot contract.

Quick Test → SCOP Starter → Advanced Runtime use_case_id + context + metrics Legacy vectors preserved separately

Three customer modes

Mode Use it for Customer effort
Quick Test First successful request using text only Low
Starter Scaffold Editable SCOP request with structured metrics and optional controls Medium
Full Payload Direct native runtime payload with fixed vectors and full control values High

Default vs advanced path

The default starter path is SCOP Method 2:

The fixed-slot vector contract still exists underneath the runtime. Customers should use the legacy vector starter only when they intentionally want direct native payload control.

How the scaffold works

  1. Start with the customer context text.
  2. Generate a starter scaffold for a supported use case.
  3. Add structured metrics for the use case contract.
  4. Adjust policy or execution controls only when governance posture needs refinement.
  5. Use the legacy vector path only for advanced direct-runtime control.

Builder command

node scripts/generate-evaluatordpt-starter-scaffold.js \
  --use-case PRODUCTION_RELEASE \
  --decision-question "Should this release candidate go to production?" \
  --context-text "Production deployment review for RC-24. Core functional validation, rollback readiness, monitoring readiness, and support runbooks are in place, but one medium-risk defect remains open, certifier posture is not fully clear, and final stakeholder approval is still pending." \
  --output docs/docs-next/examples/evaluatordpt-starter-scaffold-retail.json

Current local example

The local package currently includes a default SCOP starter example for PRODUCTION_RELEASE and a preserved legacy vector starter for advanced internal use: