Business story
The Contrive platform (codename NeoStory)
The system, from durable contract to real-world play
A source-backed map of how Contrive products use the platform's contracts, local-first data, processing, reviewed evidence and deterministic game authority—without mixing domain vocabulary into the core.
Snapshot a59c206cec9dneostory-schema-set/22161 evidence files
Guided table of contents
Start with the story you need to tell
DeclaredImplementedObservedPlanned
Product and trust
How capture, assistance, review, sign-in, and play become one legible user journey.
Engineering architecture
The contracts, replica, engines, composition seams, and operational topology behind the product.
Operations and assurance
Where identity, state, release artifacts, telemetry, and merge gates are controlled and verified.
Start here
Product vocabulary, system landscape, and the trust model.
01
Platform overview
One platform turns real-world evidence into durable, playable knowledge
Business · Product · Engineering · PDF ready02MCP capability map
One customer journey, distinct MCP authorities
Customers · Product builders · Operators · PDF ready03From a sighting to a personal field guide
From a sighting to a personal field guide
Customers · Product builders · Operators · PDF ready04From field notes to a customer-owned application
From field notes to a customer-owned application
Customers · Product builders · Operators · PDF readyContracts and data
Schema authority, generated projections, local persistence, and synchronization.
Core flows
Identity and the signature evidence-to-play product journey.
Engines
Durable processing and deterministic game execution.
Platform boundaries
Contracts, modules, domains, composition roots, and extension rules.
11
Extensibility contract
Domains extend the platform at composition seams, never by teaching Core their vocabulary
Engineering · Partners · PDF ready12Customer delivery
From a customer-owned domain to a pinned application release
Business · Partners · Engineering · Operations · PDF ready13Deployment business cases
Dedicated deployments and shared infrastructure
Business · Partners · Engineering · Operations · PDF readyOperations
Artifact-pinned promotion, deployment isolation, telemetry, and public-edge proof.
Shared language
Four names, four distinct responsibilities
- Contrive
- The company and the brand at every altitude. Contrive Skate is the first product; Contrive Birding follows. Prose says "the Contrive platform", never a bare codename.
- NeoStory
- The codename of the Contrive platform, and the locked prefix of its identifiers: bundle ids, data directories, Swift products, package and environment names, cookies and wire formats. In prose it appears once, after the descriptor: "the Contrive platform (codename NeoStory)".
- Contrive Observatory
- The authenticated inspection surface for schema, records, processing, proofs, and live authority state.
- Contrive Atlas
- The durable, publication-safe architecture narrative. It explains the system without depending on live user data.
Architecture invariants
The rules that keep the platform coherent
- Core is domain neutral
NeoStoryCore imports no domain, UI, database or platform package.
2 evidence sources - Schema is the portable contract
Stable schema packages and schema-set pins define cross-platform meaning; generated code is a checked projection.
4 evidence sources - Domain knowledge enters explicitly
Domain code and presentation register only at declared composition points, with generic Explorer imports guarded by test.
2 evidence sources - Prediction is evidence, not truth
Machine proposals remain immutable inputs to review and never silently become accepted semantic events.
2 evidence sources - Operational state is not a second graph
Queues, leases and caches coordinate work while semantic state remains ordinary graph records.
2 evidence sources - The game kernel stays pure
Rules interpret pinned records and admitted evidence; they never invoke camera, model, blob, UI or authorization infrastructure.
2 evidence sources - Shared history is authority accepted
Local forecasts are provisional and shared game state is replayed from append-only accepted events.
2 evidence sources - Identity may span deployments; data does not
A shared OIDC identity may resolve to the same principal while every deployment retains separate credentials, graph storage and object storage.
3 evidence sources - Promotion reuses a named artifact
A clean exact head and schema revision name one built image; production promotion re-releases the artifact that staging soaked rather than rebuilding it.
3 evidence sources - Documentation carries no live user data
The Atlas is generated only from committed contracts, code topology and curated claims; authenticated user records remain in the Observatory.
3 evidence sources - Design tokens have one source; every projection is generated
design/tokens/ is the one source for colour and type; generate.mjs projects it into the Explorer's CSS, the NeoStoryDesign Swift module and colorsets, and each domain's own web and native overlay. A generated file is never hand-edited — generate.mjs --check byte-compares every output against the source.
5 evidence sources
Generated, not recopied
The Atlas checks the structure it describes
The checked snapshot derives package dependencies from SwiftPM and package closure from the pinned schema set. Any referenced architecture evidence changing makes the snapshot check fail until the views are reviewed.
- 10
- schema packages
- 358
- descriptors
- 101
- Swift targets
- 524
- target dependencies
Explore the generated inventory and source guide17 deep guides · 161 checked evidence files