From your model to working software.

Before you begin

Workspace → EA model

Use this manual while working in WanOne. The Configuration document explains the model concepts in more depth.

1. Sign in. If you have a free account, choose Browse for free to explore, or Create my own workspace to choose a paid plan and set up a workspace.
2. Open your workspace and select the EA model you intend to edit. Creating and saving architecture requires the appropriate workspace permissions.
3. Gather a small example: who places an order, which data is needed, how the order is confirmed, and what should happen if a step fails. Use that same example throughout configuration.

Check before continuing The screenshots use Ember Sand. BA, AA, and DA crops come from the retail and illustrative banking demos; newer Generation controls use fictional checkout examples. They are focused views, so surrounding navigation may be omitted. Example verification results do not certify your generated output.

1. Define reusable Data Domains

Business Architecture → Data Domain

A Data Domain gives an attribute a shared meaning, data type, and optional allowed values.

1. Choose + Domain. Enter the business name, technical name, description, and data type. Use a business definition that another team can understand.
2. Select the domain kind and status. For a list of allowed values, choose Enumeration, save the domain, then add its codes and display values under Domain Values.
3. Decide whether values outside that list are allowed. Review length limits and active values. Use a lifecycle domain when you need to track which process steps use its stages.
4. Save the definition and each value. Assign the domain to the relevant attributes in Data Modelling.

Before moving on An enumeration defines permitted values; process rules define permitted transitions. It does not automatically create a lookup table.

2. Build the business data model

Business Architecture → Data Modelling

Work from A concepts to B subject areas, C entities, and their attributes. The banking demo illustrates the same structure used for a retail Order.

1. Select the appropriate A concept, then create or select its B subject area. Group information by business meaning rather than by application screens.
2. Add a C entity such as Customer or Order. Give it a clear business name and definition. Reuse an existing entity when it represents the same business concept.
3. Add its attributes. Review names, meaning, data types, keys, and applicable Data Domains. For an Order, include the identifier, status, and the details needed by its processes.
4. Define the relevant entity relationships and attribute references. Review the Business view for meaning and the Technical view for the corresponding names and types. Save your edits.

Before moving on An attribute such as Order ID is a business identifier. Business entities and relationships should be connected before deriving database tables.

3. Structure the business process

Business Architecture → Process Modelling

Use the navigator to move from the business landscape into a specific workflow.

1. Create or select the L0 Business Domain Layer and L1 Business Domain. Organize work into an L2 Value Chain and L3 Business Activity.
2. Under the activity, add or open an L4 Business Process. In L4 Details, describe its purpose, scope, expected outcome, and relevant business rules.
3. Configure how the process continues to the next L4, then select the child-step execution mode and failure handling. Make branch conditions and exceptional outcomes explicit.
4. Save the process. For the Click & Collect example, make clear when an order is placed, prepared, and physically handed over, and who is responsible for each action.

Before moving on An empty continuation or recovery field may be a decision to finish. A complete-looking description alone does not establish a valid executable sequence.

4. Configure L5 data and features

Business Architecture → Process Modelling → L4 process → L5 Step Setup

Describe the behavior of each individual step, including the data it uses and the outcome it produces.

1. Open L5 Step Setup and select the step. In L5 Details, review its actor, channel, execution behavior, conditions, and completion rule where applicable.
2. Open Data. Select the business entities and attributes the step reads, requires, creates, or changes. Choose existing data definitions rather than describing unrelated duplicates.
3. Open Features. Add or select a feature, give it a meaningful name, and describe What this feature does. Configure its behavior and data operations.
4. Choose the Processing intent: a transaction for one business request, an operational batch for business work over a dataset, or a data pipeline for moving or transforming datasets. Complete the relevant input/output and processing settings.
5. Review Overview and Interpretation review. Save the changes. For checkout, state the invalid-quantity behavior and whether an order must save atomically.

Before moving on Keep business rules in the model. A temporary generation instruction should not be the only place that records a required rule.

5. Review services and operations

Business Architecture → Service Modelling

Service Modelling connects process responsibilities to business data and the operations that implement them.

1. Save the data and process changes first. Generate or regenerate the service model when you intend to derive it from the current saved model, then inspect the result.
2. Select a service in the left navigator. Read its responsibility, operations, and actions. Use the BPM context to trace it back to the business activity and steps.
3. Use the BDM context to check the entities and attributes involved. Open each relevant operation and verify its inputs, outputs, changes, and processing intent.
4. Resolve missing or conflicting business decisions in the owning data or process editor, then review the service model again. In Application overview, review how those responsibilities fit together before assigning them to applications.

Before moving on Services describe business responsibilities. Application Architecture assigns their implementation ownership and execution settings.

6. Use AI assistance with clear boundaries

Business Architecture → AI Assistant

Use the assistant to create or refine the model while keeping your business decisions explicit.

1. Select the intended EA model, then describe the business goal, actors, information, process, and exclusions. For example: “Model customer ordering and store collection. Preserve submitted prices. Exclude payment and stock reservations.”
2. Open Settings. Check the connection and spending controls. Enable Review before apply if you want to inspect proposals before they change the model. When it is off, eligible validated changes may apply automatically.
3. Read the named changes, assumptions, and validation result. Ask for a revision when a suggestion changes your intent, or confirm the reviewed proposal when appropriate.
4. Inspect the saved result in Data Modelling, Process Modelling, and Service Modelling. Resolve missing decisions rather than treating an assistant completion message as a complete model.

Before moving on Optional AI review in Generation Runs is a separate flow and requires explicit confirmation. It does not inherit the authoring assistant’s automatic-application setting.

1. Save the architecture approach

Application Architecture → Architecture Approach

Open Application Architecture and choose the organization that fits your delivery teams.

1. Choose Full-stack applications when each application groups its experience, services, and data configuration. Choose Frontends with shared services when several experiences share backend systems.
2. Select Save and continue. Open Applications or Systems, according to the saved approach.
3. Create or select the design. Assign its journeys or processes, then complete frontend, service, data-store, and integration choices. Select supported releases where required and save.
4. For analytics work, also complete the relevant Data Architecture platform, data application, and mappings. See Data Architecture configuration.

Check before continuing Deployment is configured separately. Switching the approach retains existing designs and output; older generation runs may be available as read-only history.

2. Configure scope and frontend

Application Architecture → Applications or Systems

Choose which business experience the application delivers before selecting its technology.

1. In Applications, create or select a full-stack application. In the shared-services approach, use Systems to configure a frontend system and its backend providers.
2. Give the design a useful name and purpose. In Application scope or System scope, select its L3 journeys or L4 processes. Review the supporting services that follow from those assignments.
3. Open Frontend. Select the framework and release, language, navigation, landing journey, and authentication behavior. Review frontend roles and channels from BPM.
4. If you use Auto recommend, inspect every suggested change. Complete fields marked Needs decision, then save the design.

Before moving on The demo shows pending language and authentication choices. Recommendation is a draft, so resolve required decisions before generation.

3. Assign services and runtime choices

Application Architecture → Applications or Systems → Services

Keep service ownership and per-service execution choices explicit.

1. For a shared backend, select the supporting business services under System scope. For a full-stack application, review the services associated with its business scope.
2. Open Services. Review the default runtime and its selected release, then select the service architecture appropriate to the application.
3. Expand each service under Service execution settings. Review its processing pattern, runtime, version, and supported execution settings. Defaults do not silently replace per-service choices.
4. Check the remaining configuration decisions and save. Data-pipeline workloads belong in Data Applications under DA.

Before moving on The demo intentionally shows a runtime release still to be pinned. Select an appropriate supported release in your own design.

4. Configure data stores and database design

Application Architecture → Data store / Database Design

Preserve the connection between business information and its operational database realization.

1. Open the design’s Data store tab. Select the database engine and supported release where required. Assign the business entities that belong to the store.
2. Open Database Design. Review the generated or existing tables against the BDM hierarchy. Use the available build or regenerate action deliberately, then inspect its result.
3. Open a table to review columns, data types, keys, nullability, constraints, and the business attributes they realize. Resolve missing mappings before continuing.
4. Review Integrations for external dependencies or shared-system provider connections. In Reference Catalogs, inspect available technology releases and patterns when a configuration choice is missing.

Before moving on A table definition is an architecture artifact. It does not establish that a database has been provisioned, migrated, or tested.

1. Set the Data Platform

Data Architecture → Data Platform

Configure the shared analytical layers before configuring the pipelines that connect them.

1. Select the database engine for SA (Staging Area), EDW (Enterprise Data Warehouse), and ADW (Analytical Data Warehouse).
2. Review Pipeline Defaults for the transfers from the operational database to SA, SA to EDW, and EDW to ADW. Choose patterns that match your intended data movement.
3. Save the shared settings. Revisit them when a layer’s engine changes, and reconcile older descriptive notes with the selected configuration.

Before moving on BigQuery is the selected engine in this demo, not a required engine for every workspace. Configure the choice that fits your own architecture.

2. Configure a Data Application

Data Architecture → Data Applications

A Data Application owns the pipeline services and their processing configuration.

1. Create or select a Data Application. Enter its name and purpose, then open Data application scope.
2. Select the relevant data-pipeline services. Transactional services belong in AA, rather than being added here simply because they use data.
3. Open Pipeline setup. Review the layer engines from Data Platform, the optional dedicated runtime, and service architecture.
4. Expand each pipeline. Configure its processing pattern and execution settings, then bind each operation’s inputs and outputs to the intended data layers and tables. Save the configuration.

Before moving on The shared layer engines and a dedicated pipeline runtime serve different purposes. Verify the input/output table mappings for every operation.

3. Map operational data into SA

Data Architecture → SA Data Model

The Staging Area is the landing layer for operational source data.

1. Review the RDBMS tables on the source side. Expand a table to inspect its columns.
2. Select the tables required by the analytical scope. Use the available synchronization action when you intend to bring the required source structures into SA.
3. Inspect the Staging Area tables and the source mappings. Preserve the connection to the operational tables and business attributes.

Before moving on Source-derived SA structures may be read-only or locked. Correct their definition in the owning source editor; do not treat synchronization as proof that data was loaded.

4. Build the enterprise warehouse layer

Data Architecture → EDW Data Model

EDW integrates staged information while keeping consistent business meaning and lineage.

1. Review the Staging Area tables available as sources and the existing EDW targets.
2. Use the available build or synchronization action, then inspect the resulting enterprise tables. Review names, keys, relationships, history choices, and mappings.
3. Open an editable target to review its columns and realized attributes. Check that related business concepts remain consistent across sources and save deliberate changes.

Before moving on An integrated schema still needs appropriate transformation logic and data-quality checks. A successful model build does not prove a pipeline executed.

5. Shape analytical subjects and columns

Data Architecture → ADW Data Model

Make the reporting grain and source mappings explicit before generating analytical code.

1. Configure the analytical subject and its grain: describe exactly what one fact row represents. Select the relevant EDW source tables, including their parent and dimension tables.
2. Build or synchronize the intended analytical structure. Review the fact and dimension tables shown on the target side.
3. Open a target table. Review its columns, data types, Data Domains, nullability, and Realized from Attribute mappings. Add columns from the appropriate entity when needed.
4. Save the analytical design. Return to Pipeline setup to confirm that operation inputs and outputs refer to the correct layer and tables.

Before moving on The retail demo’s fact_order_item illustrates an order-item grain. Choose and verify the grain for your own analytical question; the displayed model does not establish deployed warehouse behavior.

1. Create a run and save scope

System Generation → Generation Runs

A Generation Run keeps the intended work and generated history together.

1. Open Generation Runs with the intended EA model selected. Choose New run.
2. Enter a short name and description. For example, “Checkout — first preview” and “Preview placing and confirming an order.” Create the run.
3. In Scope, select the applications, shared systems, or data applications to include. Under each design, select the BPM processes to implement.
4. Save the scope before running validation. Confirm that the run name and included processes match your intended delivery.

Check before continuing Unselected designs remain outside the implementation scope. Referenced interfaces can still be retained as external dependencies. Shared processes are included once.

2. Resolve deterministic findings

Generation Runs → Deterministic Validation

Deterministic Validation checks the saved model without an AI request.

1. Open Deterministic Validation for the selected run and run the available check.
2. Expand a section with findings. Read the required change and the named source. For a missing release, open the corresponding architecture design and select the release.
3. Save the correction in its owning editor. Return to the same run and validate again.
4. Resolve all required findings before generation. Optional AI review does not override these requirements.

Check before continuing If generation says “Resolve deterministic validation findings,” return here. Repeatedly requesting an estimate will not correct the saved model.

3. Inspect the model interpretation

Generation Runs → Model Assembly / Journey Interpretation

Read how the saved scope will be understood before asking for generated software.

1. Open Model Assembly. Choose BPM, BDM, BSM, AA, DA, or Context, then select an item to inspect its readable configuration.
2. Open Journey Interpretation. Review the intended steps, business rules, and expected outcomes. An outcome preview explains modeled behavior; populated results require suitable data and a running implementation.
3. If the walkthrough reports an incomplete or ambiguous L4 sequence, correct the process connections in BPM, save, then validate again.
4. Use the download action when you need a saved interpretation to review or share. The formatted interpretation is a derived reading of the model, not a replacement for editing the saved model.

4. Request optional AI review

Generation Runs → Optional AI review

Optional AI review helps identify missing detail and prepares proposals for your review.

1. Open Optional AI review. WanOne Agent appears first and is the default. Select AI API if that is your preferred available method.
2. Enter your request in Review instructions (optional). State the goal, what must stay unchanged, and which decisions require your input.
3. Example: “Review order completion. Preserve submitted prices. Ask me before changing payment or retry rules.”
4. Choose Request Agent proposals or the corresponding API action. Wait for the review, then load the proposals when that action is offered.

Check before continuing For a detailed request, use a short structure: Goal → Current behavior → Desired behavior → Constraints → Acceptance examples. Only rely on attachments if the current UI explicitly supports them.

5. Refine and confirm proposals

Optional AI review → Proposals → Confirm

Proposals are suggestions. Read the change and resolve business decisions before applying it.

1. Open each proposal. Read its rationale, proposed changes, assumptions, and validation result. Reject or refine a suggestion that changes your intent.
2. If a business decision is required, enter your decision and choose Save refinement. For example: “Retry once, then ask the customer to retry.”
3. Select only the proposals you want to apply. Choose Review selection and confirm.
4. Read the final selection. Choose Cancel to return without saving those changes, or Confirm and save to apply them. Review the deterministic checks afterward.

Check before continuing The optional review confirmation applies to this review flow. Authoring assistant behavior also depends on its separate Review before apply setting.

6. Choose source, target, and budget

System Generation → Generate

Keep the starting source, current model, output target, and spending limit clear.

1. Choose Improve a version and select an existing version to retain its source and UX while applying the current EA model. Choose New version to build from the current model and saved scope.
2. Select Preview for a runnable workflow and UX review, Configured target for the configured implementation, or Both for both outputs.
3. Read the estimate and set the available spending controls. Confirm that the model, run, source version, and target are correct, then start generation.
4. Use resume for continuing the saved attempt. Start a new attempt when you intend to change the starting point or target. Review generated changes even when improving a version.

Check before continuing Improving a version preserves a starting source; it does not guarantee that only a particular set of files will change. The current model and scope still govern the requested work.

7. Review UX and verify the source

Generate → Selected output / Code Review

A generated version needs separate checks for code and user behavior.

1. Open the intended generated version. Run Source checks, then inspect failed checks and their output. Rerun after corrections.
2. Open UX Review when the selected version has an available preview. Exercise the journey, including invalid inputs, empty states, and recovery behavior.
3. Use Code Review to inspect generated files and distinguish preview output from the configured implementation.
4. Check browser acceptance independently. Record what was actually exercised; a passed build does not establish that a user journey passed.

Check before continuing If UX Review cannot open, confirm that the chosen version contains a runnable preview and inspect its startup result. Configured source alone does not provide a live UX preview.

8. Trace changes and improve a version

Governance / Impact Review / Generate

Use the right history for the artifact you are reviewing.

1. In EA Model Governance, label important saved model versions. Use Model Version Diff to compare readable before-and-after changes.
2. Keep model versions and generated code versions distinct. A model label identifies saved architecture; a generated version identifies an output attempt.
3. After changing the model, revisit scope and validation, then improve the intended code version or generate a new one.
4. For an application failure, open the relevant dashboard error report and use its copy-details icon. Include the copied report, the action you attempted, and what you expected when requesting support.

Check before continuing Before deployment, verify the intended configured output in its target environment. A local preview, a history label, or a review confirmation does not deploy software.