Technical diligence brief
Status vocabulary
Every capability on this page carries one of five statuses. Implemented: exists and runs in the operating product. Demonstrated: shown on video with a timestamp (see the evidence ledger). Internally validated: exercised by Deckwright's own automated tests or daily use building Deckwright itself. Externally validated: verified by a party outside the project - none yet claimed. Planned: not yet built.
Operator
Deckwright is designed, built, and operated by Kevin Hincker (Los Angeles), a three-time software founder and professionally published novelist. The team is currently one person; that is a stage description, not a philosophy.
Current product status
Deckwright is an operational, multi-tenant context-development platform. It is in daily use as the development environment for its own codebase: the capture layer, officer crew, and gated production pipeline shown in the walkthroughs are the same systems used to design, implement, and evolve Deckwright. Multi-tenant accounts, authentication, and account management are built and live. It is in private beta with access by request via the contact page; no external customers have onboarded yet.
The intended landing motion is creator-first: a visual creator or design engineer starts on the Bench, and the same deck grows into the governed pipeline as the work hardens. Multi-tenant accounts and isolated tenancy are built; the fleet-oversight layer for organizations - many engineer-captained decks under a single master bridge - is still on the roadmap.
What is operational today
| Capability | Status |
|---|---|
| Three surfaces - Bench (spatial/multi-modal canvas), Bridge (multi-officer chat), Board (governed pipeline) - operating over shared per-project context (a deck), with multiple decks supported | Implemented · Demonstrated · Internally validated |
| Multi-modal capture: voice, gesture, timing, hesitation, and canvas state fused into a durable, replayable intent record deliverable to an officer | Implemented · Demonstrated · Internally validated |
| Behavioral capture over live HTML: DOM events, dev-console errors, and network activity timestamped against user interaction, attachable as bug or feature context | Implemented · Demonstrated |
| Named, persistent, role-scoped officers (Chief Officer, Scribe, Librarian, Secretary, Mapmaker) backed by independently chosen models per role | Implemented · Demonstrated · Internally validated |
| Polyphonic context development: forward, context injection without reply, cross-thread synthesis, pruning with record preservation | Implemented · Demonstrated |
| Attach: promotion of any artifact (post, canvas element, capture, image) into governed pipeline context | Implemented · Demonstrated · Internally validated |
| Hierarchical context inheritance: board to stage to card | Implemented · Demonstrated · Internally validated |
| Staged production pipeline with explicit gates: context development stages (proposed, investigating, specified) then execution stages (task board, approved, in progress, review, complete). Gate depth is configurable per plan - full human-in-the-loop, or one-click auto-deploy with no manual stage reviews | Implemented · Internally validated (pipeline and auto-deploy option shown on video; a full execution run is not filmed) |
| Separation of duties: the builder of a card cannot approve its own work; independent review and verification precede completion | Implemented · Internally validated |
| Attestation of existing codebases: architecture, conventions, and constraints reverse-engineered into inherited context for brownfield work | Implemented · Internally validated |
| Operability through UI, HTTP, MCP tools, and scripts, with permission gates on officer tool use | Implemented · Demonstrated (MCP permission gate on video) |
| Multiple decks (projects) per installation, each with its own boards, research corpus, and inherited context - six decks operate on the current installation | Implemented · Internally validated |
| Multi-tenant account and access management: authenticated accounts, isolated tenancy, and login/account administration across separate organizations | Implemented (built and live; no external customers onboarded yet) |
| Fleet oversight: a master bridge with cross-deck visibility and organization-configurable deploy authority over many engineer-captained decks | Planned |
Current limitations
- Unproven at multi-user scale. Multi-tenant accounts and isolated tenancy are built and live, but no external customer has onboarded, so concurrent multi-organization operation is not yet proven in the field.
- No external validation. All validation to date is internal: automated pipeline tests plus daily production use on Deckwright's own codebase. No third-party audit, benchmark, or customer deployment is claimed.
- The walkthrough videos demonstrate the pipeline's structure and gates but do not film a card end-to-end from specification to deployed code.
- Scale and load characteristics are unmeasured beyond single-team use.
Security and deployment
The product runs on private infrastructure operated by the project. Officer tool use is permission-gated; consequential pipeline transitions (approval, deployment) are held by the human Captain. This public site is static HTML with one dynamic endpoint (the contact form). No product endpoints are exposed publicly.
Evidence
Timestamped video evidence for every demonstrated claim: product evidence ledger. Full transcripts: Bench, Bridge, Board. Architecture and thesis: Why Deckwright, Metaphor as harness, Multi-modal capture, Production pipeline, position paper (PDF). Independent scale assessment: what an agent said about our process. The Mission Graph and the structure-vs-provenance split: a map without a legend. Origin and second-product evidence: the first deck.