Spec-to-Stack Readiness Matrix
Use this page before Stainless-transition demos, sales calls, and partner conversations. It separates what is ready now from what needs scoping so the demo stays useful without overclaiming.
Demo Path
The recommended demo path is:
- Import or author an OpenAPI spec.
- Generate the ThorAPI backend stack.
- Show the TypeScript client generated from the same contract.
- Connect the running stack to GrayMatter memory.
- Explain TrustFabric posture and audit boundaries.
- Scope deployment as hosted, isolated customer instance, or custom enterprise delivery.
Capability Matrix
| Capability | Status | Demo-call language | Engineering route |
|---|---|---|---|
| OpenAPI source of truth | Ready | "The spec is the contract. Backend and TypeScript client output are generated from it." | Keep api.hbs.yaml and generated output in sync through ./vaix generate and CI drift checks. |
| ThorAPI backend generation | Ready | "Valkyr generates Spring/JPA backend surfaces from OpenAPI, including generated models, repositories, services, and delegates." | Scope custom behavior through thin delegate overrides or ThorAPI templates, not handwritten duplicate CRUD. |
| TypeScript client generation | Ready | "TypeScript is the first-class production client today and is regenerated from the same OpenAPI contract." | Use generated ThorAPI client services and freshness checks before release. |
| Broad multi-language SDK parity | In progress | "We are not claiming Stainless-style multi-language SDK parity today. Additional language SDKs are scoped by customer requirement." | Open targeted SDK issues per language and bind them to customer requirements. |
| Docs/MCP parity from specs | In progress | "MCP and docs surfaces are part of the platform direction, but each customer-facing route should be validated against the current generated artifact." | Verify MCP publishing and docs generation for the selected spec before committing delivery language. |
| RBAC and ACL enforcement | Ready | "Generated object surfaces are designed to run under RBAC/ACL controls, with custom behavior kept thin so generated security stays intact." | Validate role, owner, and explicit ACL cases for the demo object set. |
| SecureField posture | In progress | "Encrypted-field handling is a core security track. We should scope exact field-level requirements before promising a production control package." | Route field encryption, key management, and weaving/codegen blockers to SecureField issues. |
| TrustFabric posture | In progress | "TrustFabric is the trust/audit narrative around generated runtime, memory, RBAC, and operator controls. We can demonstrate the posture, then scope evidence depth." | Bind claims to current audit logs, memory receipts, RBAC tests, and deployment evidence. |
| GrayMatter install and use path | Ready | "GrayMatter can be demonstrated as schema-aware memory tied to the running business object graph." | Use hosted readiness checks and credit/auth recovery paths before external demos. |
| Stripe-paid plans and revenue path | In progress | "Paid conversion and credit accounting are active platform tracks. We should demo only flows that have current checkout and entitlement proof." | Validate checkout, webhook, credit ledger, and entitlement state for the selected scenario. |
| Isolated app instances | Custom scoping | "We can scope isolated instances for customer needs, but this is not a one-click commodity promise for every prospect today." | Define hosting, tenant boundary, data residency, observability, and support requirements before quote. |
| Deployment flow | In progress | "Deployment is part of the spec-to-stack story. The exact path depends on whether the buyer wants hosted Valkyr, private cloud, or isolated instance delivery." | Choose deployment profile, health checks, rollback path, and support model per pilot. |
Approved Status Language
- Ready: "We can demonstrate this today and tie it to current product behavior."
- In progress: "This is an active platform capability. We can show the direction, but production commitments need scoped acceptance criteria."
- Planned: "This is on the roadmap. Do not sell it as available without an explicit engineering commitment."
- Custom scoping: "This depends on customer environment, security requirements, or delivery model. Scope it before committing."
- Not a fit: "This is outside the current product focus or would pull the customer away from the spec-to-stack value path."
What Not to Say
- Do not call Valkyr a drop-in Stainless replacement.
- Do not claim broad multi-language SDK parity beyond the current TypeScript-first client path.
- Do not promise isolated instances, TrustFabric evidence depth, SecureField completeness, or Stripe production readiness without current proof for that buyer's scenario.
- Do not use "coming soon" as a substitute for a status. Use Ready, In progress, Planned, Custom scoping, or Not a fit.
Demo Prep Checklist
- Pick the customer spec or a sanitized sample spec before the call.
- Confirm the generated backend and TypeScript client are fresh against the OpenAPI contract.
- Prepare one GrayMatter memory action tied to a real business object.
- Prepare one RBAC or tenant-boundary proof point.
- Decide whether deployment will be presented as hosted, isolated, or custom-scoped.
- Bring one blocker issue for each In progress capability the buyer asks about.