VerityJX™ Architecture
A deliberate execution model for verifiable user journeys
Architectural intent
The VerityJX™ architecture is intentionally simple.
It separates human expression, intent representation, and automated execution into distinct layers, ensuring that user journeys remain stable, understandable, and executable even as tools and technologies evolve.
At its core, VerityJX™ treats user journeys as the source of truth, with automation as an optional delivery mechanism rather than a prerequisite.
High‑level architecture overview
Definition → Intent XML → Execution
Execution may be manual or automated; the architecture ensures journeys are useful immediately and automatable later without redefinition.
This separation is fundamental to VerityJX™ and enables extensibility without compromising user‑centred expression.
Layers
Layer 1
Journey Definition
Purpose
Capture real‑world user journeys in a form that business users can author, review, and maintain.
Characteristics
- • Tool‑agnostic
- • Structured, not scripted
- • Plain‑language semantics
- • Reviewable without technical knowledge
Supported definition tools
- • Spreadsheets
- • Collaboration tables
- • Forms, CSVs, lightweight databases
Architectural constraint: Definition tools must optimise for human comprehension, not automation convenience.
In many organisations, this layer alone provides immediate value by standardising manual acceptance and preserving shared understanding of critical journeys.
Layer 2
Intent Transformation
Purpose
Convert structured journey definitions into a consistent, machine‑processable format without losing human intent.
Responsibilities
- • Normalise terminology and structure
- • Preserve journey semantics
- • Reject technical leakage
- • Produce a stable representation suitable for validation and execution
This transformation is deterministic and repeatable.
Layer 3
VerityJX™ Intent XML (Canonical Contract)
Why XML is the centre of the architecture
XML is the canonical representation of user intent. All downstream processing operates from this contract.
Properties of Intent XML
- • Human‑readable
- • Structurally rigorous
- • Independent of execution tooling
- • Compatible with XML‑aware tools
- • Stable over time
Intent XML (example excerpt)
<test case="View Articles"> <step action="Click" input="Insights" element="[TOP_MENU_ITEM]"/> <step action="Capture" element="[COMING INSIGHTS]" outcome="[SCREENSHOT]"/> <step action="Analyse" input="Insights" element="[SCREEN]"/> </test>
This is the contract: actions, targets, expectations — without locators or tool instructions.
Layer 4
XML Tooling Layer (Optional but Powerful)
Purpose
Enable validation, enrichment, and analysis without breaking user‑centred design.
Examples
- • Schema validation
- • Journey tagging
- • Risk classification
- • Transformation to multiple execution engines
- • Reporting and audit tooling
Critical constraint: Tooling must preserve user‑centred expression and avoid technical abstractions.
Layer 5
UI Execution (Manual or Automated)
Purpose
Execute user journeys against real applications in real environments.
Characteristics
- • Selenium / WebDriver
- • Browser‑agnostic
- • Triggerable on demand or schedule
- • Derived exclusively from Intent XML
Automation frameworks are replaceable. Intent is not.
Layer 6
Journey Outcomes & Evidence
Purpose
Provide confidence that user journeys continue to work as expected.
Outcome formats
- • Human‑readable summaries
- • Journey‑level pass/fail indicators
- • Machine‑consumable outputs (CSV, XML, JSON)
- • Integration with dashboards or alerting systems
Architectural principle: Outcomes must be understandable by the same audience that authored the journeys.
Why this architecture works for software consumers
Traditional test automation architectures assume:
- • Long‑lived test codebases
- • Dedicated engineering teams
- • Tight coupling between tests and implementation
VerityJX™ deliberately avoids these assumptions.
By anchoring intent in XML and isolating execution concerns, the architecture supports:
- • Vendor‑supplied software
- • Limited testing resources
- • Frequent external releases
- • Long‑term maintainability
Extensibility without lock‑in
Because VerityJX™ uses XML as its intent contract:
- • Execution engines may change
- • Reporting tools may evolve
- • Validation rules may grow
- • Definition tools may vary
None of these changes require rewriting user journeys.
Execution tools may change.
Journeys must not.
Architectural summary
- • User journeys are authored in plain language
- • XML is the canonical contract for intent
- • Automation is a delivery mechanism
- • Tooling layers must preserve usability
- • Outcomes provide acceptance confidence
- • Evidence includes logs, CSV, screenshots, videos, dashboards
This is the architectural foundation that enables VerityJX™ to remain user‑centred, extensible, and effective in environments where organisations consume — rather than build — software.