Enterprise AI Workspaces Need Contract-Parity Accountability, Not Route Counts Alone
Enterprise AI workspaces can look mature because they expose many routes, packages, and assistant tools. Route counts alone do not prove that a user-facing capability is safe, typed, encrypted, recoverable, and supported by the assistant runtime. This workspace-grounded conceptual synthesis studies an nk304 monorepo through its AGENTS guidance, root scripts, generated OpenAPI contract, WebSocket contract artifact, shared API client, assistant graph, assistant tool registry, and protected transport module, then compares the design with OpenAPI, OWASP ASVS, and NIST SSDF guidance. The contribution is a contract-parity accountability ledger with seven stages: feature surface, generated contract, shared client, protected transport, assistant read path, prepared mutation path, and verification gate. The local checkout shows a large API surface, a generated OpenAPI 3.1 artifact with 326 paths and 409 operations, a five-node assistant graph, and an explicit protected-field encryption module. The conclusion is that enterprise AI workspaces should report the weakest verified parity stage for each capability, not merely the number of endpoints or tools.
Introduction
A large workspace can accumulate hundreds of routes, packages, and assistant actions while still leaving users exposed to drift. The inspected nk304 workspace describes a multi-surface product with a Next.js web app, FastAPI API, ARQ worker, shared packages, generated contracts, API SDK, app core, locale bundles, WebSocket payload types, protected transport, and an assistant runtime [[cite:nkAgents]].
This paper asks how such a workspace should report capability readiness. The answer is contract-parity accountability: a capability is not mature until the HTTP contract, shared client, protected transport, assistant read path, prepared mutation path, and verification gate are all visible.
Method
The study mode is workspace-grounded conceptual synthesis. I inspected the repository rules, root package scripts, generated OpenAPI artifact, contracts README, API SDK, assistant graph, tool registry, and transport encryption module, then bounded the analysis with OpenAPI, OWASP ASVS, and NIST SSDF sources [[cite:contractsReadme,openapiSpec,owaspAsvs,nistSsdf]].
Two local counts are used as descriptive context, not performance metrics: the inspected OpenAPI artifact declares version 3.1.0 and contains 326 paths and 409 operations [[cite:openapiLocal]]. The assistant graph has agent, tools, finalize, policy gate, and resume executor nodes [[cite:assistantGraph]].
Results
The first result is that nk304 already has several parity anchors. Contracts are documented as the single source of truth, the API client centralizes cross-cutting request behavior, the assistant graph routes mutation-like work through policy and resume nodes, and protected text fields are explicitly enumerated before transport encryption [[cite:contractsReadme,apiSdkLocal,assistantGraph,transportCrypto]].
The second result is a risk boundary: route or tool presence does not prove parity. A WebSocket event type, OpenAPI operation, API client interceptor, protected field list, and assistant action can all drift independently unless the capability is tracked as a multi-stage object.
Discussion
The ledger reframes the workspace from a route inventory into a claim system. OpenAPI can prove contract shape, but not assistant support. The assistant registry can prove a tool exists, but not that the corresponding route is protected or typed. The protected transport module can prove field enumeration and envelope logic, but not that every new product surface uses it.
The useful reporting unit is therefore the weakest verified stage. A feature with OpenAPI and a web client but no assistant handoff is not assistant-ready. A prepared assistant action without route-level contract coverage is not contract-complete. This is consistent with ASVS and SSDF reasoning: security and development maturity are evidence claims, not labels [[cite:owaspAsvs,nistSsdf]].
Limitations
This paper did not run the full nk304 test suite, migrate databases, or inspect secrets-bearing environment files. It reports source-grounded design evidence and local artifact counts only.
A stronger future study should map every major capability to route, schema, WebSocket event, client method, protected-field decision, assistant read path, assistant mutation path, and test name.
Conclusion
Enterprise AI workspaces need contract-parity accountability, not route counts alone. The nk304 workspace has strong ingredients: generated contracts, a shared client, explicit protected transport, assistant graph control flow, a large tool registry, and verification scripts. The next maturity step is a per-capability parity ledger that reports the weakest verified stage.