Concepts
The product model behind Tasks, Projects, Experiences, delivery, and access
Nuxie connects the work you ask for, the artifact you review, the release you publish, and the outcome you measure. These are the terms used throughout the product and docs.
Workspace and App
A Workspace contains your team, Tasks, Projects, connected sources, and Apps. An App is the delivery and data boundary for one mobile application. Keys, environments, Products, customers, Segments, Experiences, and analytics are app-scoped.
Nuxie keeps test and live environments separate. Use the test key in debug builds and the live key in release builds.
Task
A Task is a bounded piece of work with Nuxie. It contains the conversation, evidence, decisions, and any Project changes or Proposals produced along the way.
Tasks can begin directly from New Task or from a Report that Nuxie brought forward. Completing a Task does not imply a live change was made.
Project
A Project is the editable artifact behind an Experience. It contains screens, components, visual properties, Flow routes and actions, variables, response schemas, and publish configuration.
The Task and Project can appear side by side. Nuxie and people edit the same Project, so generated work remains inspectable and changeable.
Screen and Flow
A Screen is one visual state inside a Project. Flow is the Editor mode for deciding how screens connect and what happens when the user acts or an event occurs.
A publishable Project has one starting point and at least one named Goal action on a path that confirms success.
Experience
An Experience is the app-facing delivery and measurement container created by publishing a Project. It has an active Version, delivery status, trigger, goal, re-entry and exit behavior, Journeys, responses, and optional Experiments.
An Experience is not a separate design surface. Edit its source Project, then publish a new Version.
Version and release
Every publish creates an immutable Version. The build turns that Version into a signed release descriptor plus the assets needed by the native runtime.
The SDK authenticates the release before admitting it for presentation. A failed or rejected Version never replaces the last known-good live Version.
Event, trigger, and goal
An Event is a named occurrence sent through the SDK. Events can update user properties, feed analytics, start Experiences, and advance Journey logic.
A trigger decides when an Experience may start. A Goal action marks an authored success point. Nuxie measures conversion from the real Journey and Goal events, not merely from a button being visible or tapped.
Journey and response
A Journey is one user’s durable run through an Experience. It records the active Version, progress, conversion state, and exit reason. If an Experience collects answers, its responses are associated with that Journey.
Segment and Experiment
A Segment is a named audience definition. Segments can use customer properties, event behavior, subscription state, Feature access, and other supported conditions.
An Experiment assigns users to alternative authored paths inside an Experience. Assignment and exposure are separate: a user only counts as exposed after reaching the Experiment action.
Product, Feature, and Entitlement
A Product is something a customer can buy. A Feature is a capability or balance your app checks. An Entitlement is the rule that says what a Product grants.
This separation lets app code ask whether a capability is available instead of hard-coding ownership of a particular Product.
The complete path
- You start a Task with an outcome.
- Nuxie creates or changes a Project.
- You review its Screens, Flow, and Goal.
- Publishing creates an Experience Version and signed release.
- The SDK receives the live Experience and evaluates its trigger.
- A matching user starts a Journey and sees the native Experience.
- Events, responses, purchases, and Goal actions record what happened.
- Analytics and Experiments help decide what to keep, change, or stop.