The product requirements document for SmartOne's annotation platform. Named product, target buyer, core modules, pricing model, and the technical architecture decisions that cannot be changed later without rebuilding from scratch.
3.1 · Platform Architect·artifact id: platform-spec-v0.html·2026-05-28·v0 format stub
This artifact is a format placeholder. The Phase 3 engagement builds this spec after the productization inventory and build-vs-buy memo are complete. A platform spec written before those inputs is a guess, not a plan. The structure below shows what the live spec will look like.
What this document specifies (when built)
Platform Spec v1 is the working product requirements document that an engineering team or a contractor would use to build SmartOne's annotation platform. It is not a pitch deck. It is a technical and commercial specification that answers:
What is the product called and what problem does it solve for which buyer?
What are the five core modules in v1 (the minimum viable platform)?
What does the buyer experience from the moment they log in to the moment data is delivered?
What are the data models, APIs, and integrations the platform requires?
What does pricing look like (platform fee plus usage, or usage-only)?
What is the build sequence (which module is built first, why)?
Spec structure (when built)
Product identity
Field
Content (placeholder)
Product name
[TBD based on inventory and positioning work]
Tagline
[One sentence: what it does for whom]
Target buyer
[Enterprise Physical AI team lead at a robotics or AV company]
Primary use case
[Annotation pipeline management + QA for Physical AI training data]
Pricing model
[Platform fee + usage, per Model D from the pricing spec]
[Real-time visibility into job progress, annotator throughput, accuracy]
2nd
[Build: wrap existing internal QA tool]
[Module 3: e.g., QA and reprocessing]
[Automated routing for below-threshold annotations; client visibility]
3rd
[Build]
[Module 4: e.g., Delivery and audit]
[Formatted delivery + audit trail for EU AI Act documentation]
4th
[Build]
[Module 5: e.g., Pre-labeling assist]
[AI pre-labeling to increase annotator throughput]
5th
[Buy / integrate]
Architecture decisions (the ones you cannot change later)
Decision
Options
Recommendation
Rationale
Data residency model
[Multi-region / single-region / client-specified]
[TBD: EU data residency required for French clients]
[GDPR + EU AI Act compliance]
API architecture
[REST / GraphQL / both]
[REST: simpler for integration with existing client systems]
[Buyers are integrating, not building on top]
Multi-tenancy model
[Shared / isolated per client]
[Isolated per client for enterprise tier]
[SOC 2 Type II audit trail requires data isolation]
What you need to send us to build this
Inputs needed. To build the live spec: (1) the productization inventory and build-vs-buy memo (prerequisites), (2) whether there is an engineering team to build this or whether it would be contracted out, (3) any existing client requests for a self-serve or API-based interface that reveal what buyers actually want, and (4) the alignment session decision on the capital path (this determines how much engineering investment is available).