WanOne Configuration Document

1. How to use this guide

For a guided walkthrough with screenshots, open the User Manual.

WanOne.ai configuration follows the product navigation. Level one is the main menu area, level two is the architecture function, and level three is the working page where you configure, review, build, or validate model artifacts. Available pages and actions depend on your workspace permissions and saved architecture approach.

Start with business meaning, then configure the application and analytical scope you need. Later functions reuse earlier artifacts; follow their required inputs and readiness checks as you refine the model.

Start in the right workspace

Sign in and select the workspace in which you intend to work. If offered a workspace reminder, Browse for free continues browsing; Create my own workspace opens paid workspace setup.
Select an existing EA model, or create one where your permissions allow. Model editing and generation require the appropriate workspace access; browsing alone does not grant those permissions.
For AI work, check the available connection and allowance. Personal API connections are managed in My Account → Personal API Consumption; workspace connection availability also depends on administrator settings.

A short route through the product

Model business data and processes → save the architecture approach and designs → create a Generation Run and save its scope → resolve deterministic findings → optionally request AI review → generate and verify the selected outputs.

Menu level	Meaning	How to use it
Level 1	Main product area, such as Architecture or System Generation.	Choose the broad work mode.
Level 2	Architecture function, such as Business Architecture, Application Architecture, or Data Architecture.	Choose which architecture layer you are configuring.
Level 3	Working page, such as Data Modelling, Applications, or EDW Data Model.	Create or update the actual model objects used by generation.

Keep this reference close

The shorthand behind the model

These terms describe different views of the same work. A/B/C organizes business data; L0–L5 organizes business processes. Neither is a menu depth or a generation stage.

A → B → C → Attributes

Use this hierarchy in Business Architecture → Data Modelling. A, B, C, and Attributes are all business concepts at different levels of detail. They describe business meaning, before its realization in IT.

A

Data Concept

The nine high-level business data concepts that organize related subject areas.

Involved Party · Product · Arrangement · Condition · Location · Event · Resource Item · Classification · Channel

B

Subject Area

A grouping of related business entities within a concept. Subject areas can also have child subject areas.

Example: Order Management

C

Entity

A specific business object with its own definition, attributes, and relationships.

Example: Order

Attr

Attribute

A named detail of an entity, with a business meaning and data definition.

Example: Order Date

Attributes belong to the business model too.

“Order Date” is a business attribute with a business definition. Its IT realization is a column with a name, database type, and constraints. The mapping carries business meaning into the technical structure.

Data Domain: put data standards into the model

Data Domain is a key implementation of data standards in WanOne. Define a reusable business meaning, data type, and—where applicable—allowed values, then assign that domain to business attributes. Attributes that express the same meaning can share one definition instead of being configured independently.

Define once

A reusable standard

Describe what a value means, its data type, and its allowed values when the domain uses an enumeration.

Example: a Currency Code domain with agreed currency codes and display values.

Apply consistently

Shared by attributes

Assign the same domain to attributes that have that meaning across different entities.

Example: Order Currency and Invoice Currency reference the same Currency Code standard.

How to configure it

Select the EA model and open Business Architecture → Data Domain.
Create the domain with a clear name, business definition, and data type.
Select its kind and status. For an enumeration, save the domain and define its codes, display values, and whether values outside the set are allowed.
Assign the domain to the relevant business attributes in Data Modelling.
Review the resulting attribute-to-column mappings across OLTP, SA, EDW, and ADW so the IT realization retains the standard’s meaning.

A standard connects meaning to realization.

Data Domain → Business Attribute → IT Column. The domain supplies shared semantics and an inherited data type; the column supplies the layer-specific technical representation. Review generated types and constraints rather than assuming that defining a domain automatically enforces every rule in every system.

Keep the terms distinct: a Data Domain standardizes attribute values. A B-level Subject Area groups business entities. An L1 Business Domain organizes business responsibility. Domain enumeration values remain part of the model; they do not automatically create a lookup table.

From business meaning to IT realization

C → D maps a business entity to its database table realization. Attribute → Column maps a business detail to the technical column that represents it.

C → D

Entity → Table

C is the business entity; D is its IT table realization. D is not another level of business classification after C.

Example: the business entity Order is realized as a table in the selected data layer.

Attr → Column

Meaning → Technical representation

The attribute defines what the value means. The column defines how that value is represented in the table.

Example: Order Date maps to a column with the appropriate database type and constraints.

One business definition, realizations across data layers

OLTP (RDBMS) → SA → EDW → ADW

D is realized across these data layers, with table and column structures suited to each layer’s purpose. Preserve the mappings as structures are copied, integrated, or transformed; the layers need not have identical tables or columns.

Data architecture: the realization path
Layer	Purpose	What to review
OLTP (RDBMS)	Operational transaction processing in the relational application database.	C → D and Attribute → Column mappings, keys, types, and relationships.
SA	Staging area for operational source data.	Source table and column mappings from OLTP.
EDW	Integrated enterprise warehouse data.	Integration, shared definitions, relationships, and history.
ADW	Data shaped for analytical consumption.	Analytical structures, measures, and mappings from the enterprise layer.

This is WanOne’s data architecture: business concepts realized as IT data structures across operational and warehouse layers, with lineage back to their business meaning. The OLTP configuration appears under AA; its place in this data realization path remains the same.

L0 → L5: from landscape to action

Use these levels in Business Architecture → Process Modelling. This retail example illustrates increasing detail; it is not a required naming template.

Business process hierarchy
Level	Product term	What it describes	Example
L0	Business Domain Layer	The broad layer organizing business domains.	Retail business landscape
L1	Business Domain	An area of business responsibility.	Sales and Order Management
L2	Value Chain	A connected flow within a business domain.	Order Fulfillment
L3	Business Activity	A major group of work in that flow.	Order Intake
L4	Business Process	A workflow of actions and decisions.	Order Validation
L5	Business Step	An individual action in the process.	Validate Order Details

Connect the two hierarchies: the L5 step “Validate Order Details” uses the C entity “Order” and its attributes. A linked business service describes the responsibility the application must support.

Architecture, services, and data

EA model: The selected enterprise architecture model that holds the definitions and relationships you are configuring. Check the selected model before editing or generating.
BA · AA · DA: Business Architecture defines business meaning; Application Architecture defines application choices; Data Architecture follows business-to-IT data realization across OLTP (RDBMS), SA, EDW, and ADW.
Data Domain: A reusable implementation of a data standard: shared business meaning, data type, and allowed values where applicable, assigned to business attributes.
BDM · BPM · BSM: Business Data Model, Business Process Model, and Business Service Model: the data, process, and service views within BA.
Service Pattern → Endpoint Style → Runtime Engine: The service structure, its interface or trigger (such as REST or messaging), and a compatible execution technology. The reference catalog defines available combinations.
DB Pattern · DB Engine: The persistence approach and database technology used for application data. Choose them to fit the service’s storage and access requirements.
D · Table: D is the IT table that realizes a C business entity. Its realizations span OLTP (RDBMS), SA, EDW, and ADW, with mappings that preserve the connection to the business entity.
Column: A column is the IT realization of a business attribute within a D table. Review its data type, constraints, and mappings across the operational and warehouse layers.
OLTP · RDBMS · App-DB: Online Transaction Processing describes operational use; a Relational Database Management System stores relational tables. App-DB is the application database model used to configure that operational realization.
DW-SA: The warehouse staging area in the configuration flow. Source tables and columns are copied or mapped from App-DB before the EDW model is built. This is different from a B-level business Subject Area.
DW-EDW: Enterprise Data Warehouse: the integrated enterprise data layer built from DW-SA. Review shared definitions, keys, relationships, history, and source mappings while preserving lineage to the original business entities and attributes.
DW-ADW: Analytical Data Warehouse: structures shaped from DW-EDW for analytical consumption, reporting, and measures. The full product path is App-DB → DW-SA → DW-EDW → DW-ADW.
Lineage: The connections that let you trace a data object or mapping back to its source. Use lineage to understand how business entities relate to application and warehouse structures.
Reference data: The catalog of reusable configuration choices, such as service patterns, endpoint styles, runtime engines, and database types. It is distinct from the business records a generated application manages.

From model to reviewed output

Generation Run: The selected work context for generation, its scope, checkpoints, and output. Keep the intended run selected as you move between generation pages.
Run scope: The selected applications, systems, or data applications and their assigned BPM processes. Supporting dependencies may extend beyond those processes; unselected designs remain outside the implementation scope.
Journey: An interpreted path through the business behavior in scope. Review it against the intended process, actors, and outcomes.
Model snapshot · Source baseline: A model snapshot records the model state used by an output. A source baseline is a saved code version selected for comparison or improvement. Accepting a source baseline does not approve deployment. Generation prepares its implementation contracts automatically; there is no separate manual Prepare Baseline step in the current workflow.
Deterministic Validation · Source verification: Deterministic Validation checks the saved model and scope. Source verification builds and tests a generated version and runs its configured journey checks. A model check is not evidence that generated code works; a source check is not proof of production readiness.
New attempt · Resume · Improve a version: A new attempt keeps its own output and spending history. Resume continues eligible unfinished work. Improve a version uses a selected saved version as the starting point while applying the current model and scope. Review the selected engine’s settings and stop reason before continuing.
Preview · Build · Deployment: A preview lets you inspect behavior; a build prepares a package; deployment runs the system in a target environment. A manual deployment mark records an event—it does not deploy software.

Use these terms in the generation workflow →

2. Business Architecture

Open Architecture → Business Architecture. Define the business meaning before choosing implementation technology.

Page	Configure or review	Before moving on
Data Domain	Define reusable meanings, data types, and allowed values. Assign domains to business attributes that share those meanings.	Check that the shared definition is appropriate and its intended constraints are carried into the data realization.
Data Modelling	Organize concepts, subject areas, entities, attributes, keys, and business relationships.	Use clear business names, definitions, and data types. Resolve missing definitions before binding process steps.
Process Modelling	Build L0–L5, assign roles and channels, connect process sequences and step transitions, and specify data use, conditions, rules, and completion outcomes.	Check both the L4 process sequence and the L5 steps. An incomplete or ambiguous sequence prevents a reliable journey walkthrough.
Service Modelling	Prepare and review the service framework from the modeled business behavior. Check service responsibilities, operations, actions, and their process/data associations before confirming it.	Saving and confirming the service framework are distinct. Missing business responsibility should be resolved in the model, rather than inferred from similar service names.
Application overview	Explore User journeys, Channel coverage, Lifecycles, and Design review. Select a role and channel for the journey walkthrough and inspect supporting services.	Confirm that the modeled journey, business outcomes, channel coverage, and service-design findings match the intended business behavior.

A walkthrough is a model preview.

Preview task outcome helps you explore the modeled task, its handoff, and intended result. It does not execute generated application code or create business records. Seeing a real application outcome requires generated software, suitable test data, and the relevant checks.

Using the AI Assistant

Select the intended model and describe the business change. WanOne Agent is the default method; AI API is also available when configured.
Open Settings to check the connection and spending controls. Enable Review before apply when you want to inspect and confirm the Agent’s proposed edits yourself. When it is off, eligible validated authoring changes may be applied automatically.
Review the named changes, current/proposed configuration, and clearly labeled business assumptions. Use Revise, Dismiss, or Confirm and apply as appropriate. A proposal based on an older model must be refreshed before application.
Read the validation result after application. Not checked means no completed validation result is available; it does not mean the model passed. Activity shows short progress updates rather than commands or internal model records.

The separate Optional AI review in Generation Runs always requires explicit confirmation of model changes. Its rules are different from the authoring assistant’s automatic-application setting.

3. Application Architecture

Open Architecture → Application Architecture → Architecture Approach. Select and save how applications and backend services are organized.

Approach	Design workspace	How to configure it
Full-stack applications	Applications	Create an application around its business scope. Configure its frontend, supporting services, data stores, and integrations together.
Frontends with shared services	Systems	Configure frontend experiences and shared backend systems. Assign service ownership to the backend systems and connect consuming frontends to their providers.

Step 1
Save the approach. Use Save and continue when a choice is pending. The saved choice opens Applications or Systems. Merely selecting an unsaved option does not change the active workspace.
Step 2
Define each design’s scope. Select its journeys or BPM processes and review the services, operations, roles, and data that follow from the existing model. Assign shared backend responsibilities where required.
Step 3
Complete implementation decisions. Configure the relevant frontend, service pattern, interface/trigger, runtime, data-store, and integration settings. Select active technology releases where required; a technology name without a pinned release can block generation.
Step 4
Save and validate. Resolve the design’s configuration findings. Review shared logical tables in Database Design. Use Reference Catalogs for available choices and releases; catalog availability alone does not certify generator or deployment support.

Switching the saved approach preserves existing designs and generated versions. It does not convert an old run into the new approach. Select or create a compatible Generation Run; older runs remain available as history.

4. Data Architecture

Open Architecture → Data Architecture. The data realization path remains OLTP → SA → EDW → ADW. Configure the operational database under AA, then configure shared data settings and the data applications that use them.

Page	Configure or review	Expected result
Data Platform	Set shared engines, data layers, and default transfer patterns for the EA model.	Shared data-platform choices for the model. Individual pipeline services are configured in Data Applications.
Data Applications	Define each data application’s scope, pipeline services, runtimes, and operation bindings. Save its configuration.	An explicitly configured data application that can accompany either AA approach and be selected in a Generation Run.
SA Data Model	Prepare staging tables from the operational model. Review names, columns, keys, and source mappings.	Staging structures with traceable operational sources.
EDW Data Model	Build and review the integrated enterprise layer from staging. Check consistent definitions, relationships, history, and mappings.	A conformed enterprise data layer that preserves business meaning and lineage.
ADW Data Model	Configure the analytical structure from EDW, including its declared grain, measures, dimensions, and mappings.	An analytical model with explicit business meaning. Verify that its source data and generated implementation satisfy the intended grain; building the model does not establish that by itself.

5. System Generation

The current pages are Generation Runs, Generate, and Code Review. Select the intended EA model and keep the same run selected as you move between them.

Create a run and save its scope

Step 1
Create or select a Generation Run. Give a new run a useful name and optional description. The run is tied to the model’s saved architecture approach.
Step 2
Save the business scope. Select the applications, systems, and data applications to implement, then select their assigned BPM processes. Shared supporting processes are included once. Resolve missing design/process assignments and use Save business scope before reviewing or generating.
Step 3
Run Deterministic Validation. Check the saved scope against BPM, BDM, BSM, AA, and DA. Resolve required findings in the corresponding model or design, run checks again, and save the readiness result when appropriate. These checks do not send an AI request.
Step 4
Inspect Model Assembly and Journey Interpretation. Review named configuration, process/step sequences, roles, channels, rules, operations, and outstanding decisions. Download journey interpretation (.json) exports a formatted, readable interpretation rather than internal model records. This is a description of saved intent, not proof of executed behavior.

Generation prepares the implementation contracts automatically.

The current flow does not require a separate manual baseline-preparation or baseline-approval page. Deterministic findings remain the model-readiness gate; AI suggestions are optional and do not replace those checks.

Optional AI review: request → review → confirm

Open Optional AI review below the deterministic findings. Choose WanOne Agent or AI API and check the selected method’s connection and spending controls. Opening the panel does not start a paid request.
Use Review instructions (optional) to focus the review—for example, on failure recovery or missing business decisions. Request proposals using the selected method. Instructions refine the review within the saved scope; they do not replace the model’s decisions.
Load or open the saved proposals. Inspect the rationale, expected outcome, evidence, and readable changes. Edit a supported refinement or record a required decision before selecting it for application.
Review the selection and confirm it in the dialog. Cancel makes no model change. Confirmation applies only eligible reviewed changes; changed model or review state requires another review.
Check the new deterministic result after application. Resolve remaining required findings before generating. An optional suggestion can be dismissed; it is not an extra mandatory AI gate.

Generate with the selected engine

WanOne Agent appears first and is the default engine. AI API remains available when configured. Read the controls for the selected engine; connection availability, permissions, and spending limits still apply.

Stage	What to choose	What to check
Scope & engine	Confirm the saved run, its implementation targets, and the engine.	The run matches the current architecture approach and includes the intended designs and processes.
Configure	For WanOne Agent, choose New version or Improve a version, then choose the saved version if improving. Select the generation target, connection, budget, time limit, improvement focus, and optional instructions. Review the verification setting.	Preview creates a runnable demonstration. Configured target creates source for the saved implementation choices. Both requests both outputs. These outputs have different verification requirements.
Progress	Start the attempt and follow its status, spending, saved output, and checks. AI API exposes its own attempt and continuation controls.	Recorded stages are not a time estimate. A stopped attempt or saved source alone does not mean all checks passed.
Review outputs	Select a preserved version. Run source checks, inspect journey results, open an eligible UX preview, and use Code Review or the available source-download action.	The selected version’s scope, approach, source, and verification results agree. A backend or data output may have code without a UX preview.

Improve an existing version or resume unfinished work

Improve a version starts from its saved source and existing UX/business behavior while applying the current EA model and saved run scope. It can preserve useful code; it does not promise that every file remains unchanged. Review the resulting version and code differences.
New version starts a separate implementation from the current model and scope. Existing versions remain available.
Resume unfinished task continues eligible saved work with that task’s captured target and spending history. It is different from starting a new version against changed model inputs.
For AI API, inspect its selected starting version and attempt controls. Matching saved stages may be reused during continuation; changed model or scope can require a new attempt. Do not assume Agent and API continuation controls behave identically.
Read stop reasons and remaining findings before adding budget or requesting repair. Agent spending is checked between turns, so an active turn may exceed the displayed limit. Already-sent requests can finish and remain billable after Stop.

Verify behavior, not just source availability

Source verification builds and tests the selected source version and runs configured journey checks. Configure independent EA requirements and journey checks for the run, including success, failure, retry, and actor-permission scenarios. Unmapped requirements remain Not checked; an API check does not establish browser acceptance.

Use Start UX preview or Open UX preview for a version that has a frontend entry. Preview uses isolated demonstration data and may simulate external integrations. It does not use production business records or prove that a configured target has been deployed. If preview startup fails, inspect its startup result and retry after resolving the issue.

Code Review shows the preserved source for the selected run and version. Check whether you are viewing preview source or configured implementation, then inspect or download the relevant output. Runtime configuration, external connections, native engine checks, and target-environment acceptance still need verification before deployment.

Impact Review compares current architecture with available generated and deployed evidence. Mark as manually deployed records a deployment performed elsewhere; it does not deploy software. Where offered, Cancel last manually deployed mark removes that manual record, not a recorded deployment.

6. EA Model Governance

Under Governance → EA Model Governance, use Model Version Labels to save a named model version, and Model Version Diff to compare two versions.

Choose meaningful labels and descriptions so reviewers can recognize the intended milestone.
Compare named elements, business connections, and before/after configuration. Filter by change or category and search the readable details.
A saved EA model version is different from a generated code version. Saving one does not generate, verify, or deploy code.
Restore and delete actions require the relevant permissions. Review their scope and confirmation carefully before changing model history.

7. Configuration checks

Use these checkpoints before generation. They keep the how-to workflow aligned with your enterprise architecture model.

BA data, process, and service objects are connected, not created as isolated lists.
Attributes with shared meanings use appropriate Data Domains, and their IT column mappings preserve the intended data standards.
The saved AA approach is correct; the intended applications or systems have complete scope, service ownership, technology versions, data stores, and integrations.
Every AA DB model can trace back to BA entities and service behavior.
DA platform settings, data applications, operation bindings, and SA → EDW → ADW mappings are explicit and consistent.
The intended EA model and a compatible Generation Run are selected, the scope is saved, and deterministic blockers are resolved. Optional AI proposals have been reviewed and confirmed only where intended.
The selected generated version, preview/configured target, source checks, and independent journey results are understood. Resolve required failures and distinguish Not checked from Passed before deployment.