Governed Event Architecture

The Governed Event Architecture (GEA) defines a structured model in which all significant system activities are standardised, uniquely identified and continuously processed in real time. It establishes the classification, identification and schema of events, enabling their consistent interpretation and controlled handling by downstream systems.

GEA extends existing functionality without disruption by introducing a unified, governed model in which process events are continuously tracked, analysed and acted upon through interconnected digital technologies. This is achieved by augmenting both existing and previously unstructured processes with standardised, plug-in capabilities and seamless integration.

With AI-assisted development, this approach evolves further. Rather than relying solely on predefined integrations, agent roles can dynamically define, refine and orchestrate processes through the AI interface. In this model, process structures, event definitions and workflows are progressively shaped in response to organisational needs, with the IoE framework ensuring that all changes remain standardised, governed and immediately operational.

The supporting event-driven platform is implemented as a browser-based interface within Advanced Digital Transformation, providing a single point of access for interaction, coordination and real-time visibility across the event ecosystem. Within this environment, roles are active participants whose actions, decisions and outputs are captured as structured events, ensuring full traceability and alignment.

The AI Command Line Interface (CLI) provides a direct execution layer for these roles, through AI agents such as Gemini and Claude. Through the CLI, roles can initiate tasks, query system state, generate artefacts and trigger workflows. Every command and response is formalised as an event within the IoE framework, creating a controlled translation between human intent and system execution.

Events are defined through an SDD-based interface and evaluated by the Digital Transformation Control Protocol (DTCP), which applies governed decision logic in coordination with Authoritative System Data (ASD). During system development and operation, DTCP conditionally triggers workflow activities based on rule evaluation, system state and contextual validation.

The Digital Transformation Control Protocol functions as the execution and enforcement layer within ADT. It interprets IoE-compliant events using predefined rules, contextual data (via ASD) and event lifecycle states to determine appropriate workflow actions. 

PROCESS FRAMEWORK AUTOMATION

DTCP enforces governance boundaries in real time by rejecting any operation not explicitly authorised by human-defined specifications, while continuously verifying workflow progression against intended goals. Routine operations are executed automatically, whereas non-routine operations are subject to human evaluation and approval prior to execution.

Event Domain Classification
All events shall belong to one of the following domains:

  • Demand
  • Transformation
  • Service Delivery
  • Value

Each domain defines a logical subsystem and associated control scope.
Each event shall include a unique Event ID, which serves as the primary control reference for DTCP rule evaluation, workflow routing and audit tracking.

Demand Events
The global digital transformation market is growing rapidly. By 2034, the market is generally expected to expand significantly, with forecasts suggesting growth factors ranging from 1.5x to 3x, depending on specific sectors.

  • Innovation and Improvement: Proposals, Financial Agenda Outcome and improvement requests.
  • Audits: Requests and outcomes for improvement, resource planning and value assessments.
  • Feasibility & Alignment: Economic, operational, technical and schedule feasibility, alongside business and technical alignment.
  • Stakeholder Requirements: Funding, delivery issues, delays and project practicality status changes.
  • Investment Portfolio: performance indicators, health and progress toward its value goals.

Demand Conrol Subsystem: Suggested Event ID Allocation

101000 innovation and creativity101005 improvement proposal101010 Financial Agenda Outcome101015 improvement request
102000 improvement audit request102005 improvement audit outcome102010 resource plan audit request102015 resource plan outcome
103000 value assessment audit request103005 value assessment outcome103010 business alignment status103015 technical aligngnment status
104000 strategic economic feasibility status104005 strategic operation feasiblity status104010 strategic technical feasibility status104015 strategic schedule feasibility status
105000 strategic feasibility audit request105005 strategic feasibility audit outcome105015 quality plan status105020 investment portfolio status
106000 stakeholder requirement delivered106005 development resource funded106010 implementation resource funded106015 feasibility issue
107000 delivery delay time107005 postponed107010 descoped107015 cancelled
 
Transformation Events
Digital transformation is a systems engineering process for developing, maintaining and delivering optimal solutions to meet related business requirements. As the business-technical ecosystem changes, many businesses continue to turn to technology as a means to shape their business future.
 
  • Requirements & Vision: Defining, explication, acceptance or rejection, including QA completion.
  • Solution Progress: From optimum benefit identification to work-in-progress and rejections.
  • Planning & Development: Evaluating the viability of plans and development stages.
  • Testing & Auditing: Completion of unit, security and compliance tests, including audit outcomes.
  • Configuration & Risk Management: Building configurations, testing, identifying risks and assessing failures.
  • Deployment & Assurance: Achieving or failing deployment, meeting service assurance criteria.

Transformation Control Substystem: Suggested Event ID Allocation

208000 vision requirement defined208005 vision requirement explication208010 requirement defined208015 requirement rejected
208020 requirement QA complete209005 solution optimum benefit209010 solutions work in progress209015 solutions rejected
210015 plan rejected210010 planning work in progress210020 development viability status210025 change elements defined
211010 unit test complete211011 security test complete211012 compliance test complete211015 security audit complete
211020 compliance audit complete211025 unit test audit complete211030 standards failure211035 data architecture audit complete
212005 configuration built212010 configuration work in progess212015 configuration functionally tested212020 configuration operationally tested
212025 configuration failure213005 risk identified213010 risk mitigated213015 system engineering failure
214010 service assurance criteria achieved214015 deployment status215005 Sabanes Oxley Act215015 Gramm-Leach-Bliley Act
216005 Health Insurance P&A Act216010 European Union Data Protection Directive216011 Federal Information Security Act216015 Payment Card Industry Data Security
216020 Bank Secrecy Act216025 Personal Information Protection & e-Documents Act217005 Threat Detection217015 Predictive Analytics
218005 Security Configuration218010 Automated Incident Response218011 Breech Remediation218015 Forensic Capable
218020 Security Hot Line218025 Security Intelligence
 
Service Delivery Events
Digital service delivery is a systems engineering process that includes the monitoring of; business throughput, service delivery, service availability, service satisfaction, defect rates, breaches of security, work in progress and rework levels. The service workflow includes optimising technical architectures to accommodate planned changes in capacity and utilisation.
 
  • Failures & Defects: Monitoring service and non-service failures, defect rates and outages.
  • Service Satisfaction & Transformation Efforts: Tracking satisfaction, update efforts and rework.
  • Batch & Online Performance: Analysing current, target and test batch durations and online performance metrics.
  • Throughput Capacity & Network Metrics: Monitoring maximum, actual and test capacities, network bandwidth, latency and server metrics.

Service Delivery Control Sub Stystem: Suggested Event ID Allocation

315000 service failure315005 non-service failure316005 request defect rate316010 service outage
316015 service satisfaction316020 update transformation effort316025 amend transformation effort316030 update WIP effort
316035 update rework effort316040 estimate mean delivery time317005 current batch duration317007 current online actual
317010 target batch duration317013 target online percentiles317015 test batch duration317017 test online percentiles
319005 maximum throughput capacity319010 actual throughput capacity319015 test throughput capacity318010 high/low/norm/avge I/O usage
318011 server with high average I/O318015 server with normal memory usage318016 server with high memory usage318017 server with low memory usage
318020 normal swap space usage318022 server high swap space usage318024 server with low swap space usage318025 network bandwith utilisation
318030 network latency utilisation318035 network available time utilisation319005 Business Process Monitor319015 Real-User Monitor
319005 Diagnostics319010 Service-Level Management319011 App Pulse Active319015 App Pulse Mobile
319020 App Pulse Trace319025 Systems Management
 
Value Events
Digital value examines whether expected benefits, effectiveness and efficiency has been achieved throughout project lifecycles. It also evaluates the ongoing benefit up until the associated deliverable is no longer relevant.
 
  • Improvement & Financial Costs: Tracking costs and budgets for improvements and financial agendas.
  • Strategy & Planning: Monitoring costs and budgets for strategic and planning activities.
  • Feasibility, Portfolio, & Transformation: Costs and budgets for feasibility, portfolio, design, development, QA and implementation.
  • Service Operations & Efficiency: Managing costs and budgets for SLA, operations, efficiency, capacity and business.
  • Revenue Tracking: Actual and projected revenue outcomes.

Value Control Subsystem: Suggested Event ID Allocation

420000 improvement cost420005 improvement budget420010 finance cost420015 finance budget
420020 strategy cost420025 strategy budget420030 planning cost420035 planning budget
420040 feasibility cost420045 feasibility budget420050 portfolio cost420055 portfolio budget
420060 transform design cost420065 transform design budget420070 transform development cost420075 transform development budget
420080 transform qa cost420085 transform qa budget420090 transform implementation cost420095 transform implemantation budget
420100 service sla cost420105 service sla budget420110 service operation cost420115 service operation finance budget
420120 service efficiency cost420125 service efficiency budget420130 service capacity cost420135 service capacity budget
420140 service business cost420145 service business budget420150 actual revenue420155 projected actual revenue

All IoE-compliant events are submitted to DTCP, where the Event ID and associated metadata are evaluated against control rules to determine the appropriate outcome: execution, consideration or indemnification.

Control Workbench Example

The data format below defines the required structure for event dataflows operating under the Digital Transformation Authority. It establishes a standardised representation for IoE-compliant events, enabling consistent interpretation and control by the Digital Transformation Control Protocol (DTCP).

Markup declarations act as control statements, specifying how structured data elements are defined, validated and processed within the system.

The following example represents a Demand Event: Financial Agenda Outcome (Event ID: 101010).

Document Type Definition (DTD)

<!ELEMENT event (eventId, eventDomain, sourceId, status, requestType, lifecycleState, priority, timestamp)>
<!ELEMENT eventId (#PCDATA)>
<!ELEMENT eventDomain (#PCDATA)>
<!ELEMENT sourceId (#PCDATA)>
<!ELEMENT status (#PCDATA)>
<!ELEMENT requestType (#PCDATA)>
<!ELEMENT lifecycleState (#PCDATA)>
<!ELEMENT priority (#PCDATA)>
<!ELEMENT timestamp (#PCDATA)>


XML Schema Definition (XSD)

<xs:element name=”event”>
<xs:complexType>
<xs:sequence>
<xs:element name=”eventId” type=”xs:eventId”/>
<xs:element name=”eventDomain” type=”xs:string”/>
<xs:element name=”sourceId” type=”xs:projId”/>
<xs:element name=”status” type=”xs:status”/>
<xs:element name=”requestType” type=”xs:requestType”/>
<xs:element name=”lifecycleState” type=”xs:string”/>
<xs:element name=”priority” type=”xs:string”/>
<xs:element name=”timestamp” type=”xs:timestamp”/>
</xs:sequence>
</xs:complexType>
</xs:element>

Extensible Markup Language (XML)

<event>
<eventId>101010</eventId>
<eventDomain>Demand</eventDomain>
<sourceId>PA01-0000598</sourceId>
<status>Funding Available</status>
<requestType>Business</requestType>
<lifecycleState>Validated</lifecycleState>
<priority>High</priority>
<timestamp>1661925740</timestamp>
</event>

back