Technical Design
How the Empower Companion is built, packaged, and deployed. It follows the same principles as the backend packages: delivered through the Catalog, data in DOM, and no manual setup for participants.
Note
This is a proposed design. Items marked (verify) must be validated on the target DataMiner version before the dry run.
Components
| Component | Purpose |
|---|---|
Catalog item Empower – Companion |
Installs everything below. Deployed once per DataMiner System, together with the vertical packages. |
| Companion app | Static frontend app in Webpages\public\empower-companion\, opened through DataMiner sign-in |
DOM module empower_journey |
Stores events, journeys, app versions, and feedback |
| Companion scripts | Automation scripts that save progress, check the backend, publish apps, and send the summary |
| Journey content | Per vertical: problem cards, cheat sheets, examples, starter prompts, knowledge pack extracts, and design card examples |
| Reference apps | Per vertical: one app that solves all three problems, as a deployable build and its source, to build further on in session 4 (C-09) |
The companion package is separate from the vertical packages so it can be updated without touching the backend, and so it is deployed only once on systems that host several verticals.
Architecture
flowchart LR
P[Participant browser] -->|/auth/?url=…| CA[Companion app<br/>public/empower-companion]
CA -->|GQI: read| DOM[(DOM<br/>empower_journey)]
CA -->|Execute Automation script| SCR[Companion scripts]
SCR -->|write| DOM
SCR -->|check| VB[Vertical backend<br/>DOM · services · elements]
SCR -->|publish| PUB[Webpages\public\<br/>participant apps]
SCR -->|send| MAIL[Email<br/>jarne.vynckier@skyline.be]
P -->|link| PUB
| Interaction | How | Reference |
|---|---|---|
| Sign-in | The app is opened through /auth/?url=…, so it has a DataMiner session |
DataMiner Web Services authentication |
| Read journey data | GQI query on the empower_journey DOM module, filtered on the signed-in user |
GQI – DOM instances |
| Write journey data and actions | Automation scripts executed from the app; scripts validate input and write to DOM | ExecuteAutomationScriptWithOutput (verify) |
Writes go through scripts so validation, permissions, and file system access stay on the server.
Data Model
DOM module empower_journey:
| Definition | Key fields | Notes |
|---|---|---|
| Training Event | Name, date, format (in person/online), current step (trainer marker), summary recipient (default jarne.vynckier@skyline.be), trainer user group |
One per event. Set up by the trainer. |
| Participant Journey | DataMiner user, display name, company, email, consent, event (link), vertical, chosen problems, problems built now, level, end state, Outcome Canvas answers, 30-60-90 per horizon, path into session 4 (own app/reference app), agent design card, next increment, completed steps, used catch-up shortcuts, submitted at | One per participant per event |
| App Version | Journey (link), problems covered, version number, folder name, link, source (own/reference), uploaded at, status | One per upload |
| Feedback | Journey (link), moment (J12/J20/J21), answers | One per feedback moment |
The journey is linked to the DataMiner user that is signed in, so several participants can share one system. See System Setup.
Companion Scripts
| Script | Called from | Responsibility |
|---|---|---|
Empower_Companion_SaveStep |
Every step | Validates and saves the answers of a step; marks the step as completed |
Empower_Companion_CheckBackend |
J4 | Checks that the vertical's DOM module, services, and elements exist and that the Baseline script is scheduled |
Empower_Companion_UploadApp |
J11, J19 | Receives the zipped build, validates it, and publishes it (see App Upload) |
Empower_Companion_UseReferenceApp |
J13, J14 | Publishes the reference app of the participant's vertical to the participant's folder and returns the link and source. Only available once the trainer marker has reached J13. |
Empower_Companion_SubmitSummary |
J22 | Builds the journey summary and sends it by email (see Journey Summary by Email) |
Empower_Companion_SetStep |
Trainer view | Sets the current step of the event (trainers only) |
Empower_Companion_Reset |
Manually, after the event | Removes participant apps and journey data after the retention period |
App Upload
Participants build their app with the AI App Builder and upload the build output. The companion publishes it to the DataMiner public folder and returns a link.
Build Folder Name
Before building (J9), the companion gives the participant a build folder name, for example, empower-<user>-<vertical>. One folder per participant is enough, because one app can cover several problems. The app must be built for that folder: the AI App Builder sets the base path to /public/<build folder name>/. The starter prompt asks for this, or for relative asset paths, so the app also works after upload.
Upload Flow
sequenceDiagram
participant P as Participant
participant A as Companion app
participant S as UploadApp script
participant W as Webpages\public
P->>A: Select zipped build output
A->>S: Send zip (in chunks)
S->>S: Validate (size, files, paths, index.html)
S->>W: Archive the previous version
S->>W: Publish to public\<build folder name>\
S->>S: Save App Version in DOM
S-->>A: Link to open the app
A-->>P: Show link and "Open app"
Validation Rules
| Rule | Why |
|---|---|
| Only the journey owner can publish to their build folder | Participants cannot overwrite each other's apps |
| Folder names are generated by the companion, not typed by the participant | Prevents path manipulation and name collisions |
| Maximum zip size and number of files (to define, e.g., 25 MB) | Protects the DataMiner System's disk |
Entries with .., absolute paths, or drive letters are rejected |
Prevents writing outside the build folder (zip slip) |
Only static file types are allowed (e.g., .html, .js, .css, .json, images, fonts, .map) |
Prevents server-side or executable content |
An index.html must exist at the root, or in a single top-level folder that is flattened |
Makes sure the link works |
index.html must not reference another /public/… folder |
Detects apps built for the wrong folder, with a clear message |
Link Format
The companion returns a link that opens the app through DataMiner sign-in:
https://<dma>/auth/?url=%2Fpublic%2F<build folder name>%2Findex.html
Opening /public/<build folder name>/index.html directly does not have a DataMiner session.
Versions
The link stays the same for every new upload, so links shared earlier keep working and always open the latest version. Previous versions are archived outside the public folder and listed in the journey summary.
Warning
Files in the public folder can be downloaded without signing in, and uploaded JavaScript runs on the DataMiner origin. Only use the upload on training systems, never on production systems, and remind participants not to put credentials or customer data in their app.
Reference Apps
One reference app per vertical (C-09) that solves all three problems of the vertical in one app. The same app serves two purposes:
- Session 3: Trainers use it as the answer key. It is not shown to participants before they have explored the data themselves.
- Session 4: Participants who don't continue with their own app start from it. Because it covers all three problems, it fits every participant of the vertical, regardless of which or how many problems they chose.
This supports different levels: beginners can focus on the part of the app that answers their problem, while advanced participants see a complete example that combines all three.
| Part | Use |
|---|---|
| Build output | Published to the participant's own build folder by Empower_Companion_UseReferenceApp, so they get their own link |
| Source | Downloaded or opened in the AI App Builder to build further on in session 4 (verify how the AI App Builder imports a project) |
The reference app is built with relative asset paths, so the same build works in any participant's folder.
Journey Summary by Email
Empower_Companion_SubmitSummary builds the journey summary and sends it:
| Recipient | Source | When |
|---|---|---|
| Training owner | Summary recipient field of the Training Event, set to jarne.vynckier@skyline.be |
Always, after consent |
| Participant | Email field of the journey | Only if the participant entered an email address |
| Item | Design |
|---|---|
| Sending | Through the DataMiner System's email (SMTP) configuration, from an Automation script (verify SMTP on the training systems) |
| Format | The journey summary document (Markdown with front matter) as an attachment, plus a short readable version in the email body |
| Subject | Empower journey – <event> – <display name> – <vertical> |
| Fallback | If sending fails, the companion offers the summary document as a download and an "Email this summary" link with the recipient prefilled |
| Record | The submission time is stored in the journey, so trainers see who has submitted |
The summary document has a fixed structure so it can be used directly as input for an agent that reviews all summaries of an event. The recipient is stored in the Training Event, with Jarne's address as default, so it can be changed without rebuilding the companion.
Trainer View
Users in the trainer group of the event see an extra view in the companion:
- Set the current step for the group (the trainer marker).
- See per participant: current step, completed steps, catch-up shortcuts used, uploaded apps, and submission status.
- Open each participant's latest app link.
Privacy
| Principle | Implementation |
|---|---|
| Minimal data | Only a display name is required; company and email are optional |
| Informed consent | J1 explains what is stored; J22 asks for consent again before sending |
| Data stays on the training system | Journey data is stored in DOM on the training system; only the submitted summary leaves it |
| Limited retention | Empower_Companion_Reset removes journey data and apps after the retention period (to define) |
Source Repository (proposed)
The companion is added to the Empower solution:
Empower.sln
├── Empower.Common/
├── Empower.Companion/
│ ├── Empower.Companion.Package/ package project → Catalog item "Empower – Companion"
│ ├── Empower.Companion.App/ frontend app → Webpages\public\empower-companion
│ ├── Empower.Companion.Scripts/ SaveStep, CheckBackend, UploadApp, UseReferenceApp, SubmitSummary, SetStep, Reset
│ ├── Empower.Companion.Content/ journey content per vertical (JSON) and the summary document template
│ └── Empower.Companion.ReferenceApps/ one reference app per vertical, solving all three problems (source + build)
├── Empower.Telco/
└── …
Journey content follows the consistency rules: problem cards, examples, and knowledge rules must match the package seed data.
Open Decisions
| # | Topic | Options |
|---|---|---|
| 1 | Upload mechanism | (a) Automation script with the zip in chunks (current design) · (b) A user-defined API that receives the zip. Verify the maximum parameter or body size of each. |
| 2 | Email route | (a) SMTP on each training system (current design) · (b) Send summaries to a central system that emails them · (c) Download and send manually |
| 3 | Viewing apps after the event | Links only work with access to the training system. Options: add a screenshot to the summary, attach the build zip, or keep training systems available for a period. |
| 4 | Base path in the AI App Builder | Verify whether the AI App Builder accepts a given build folder name or relative asset paths. |
| 5 | Reference app source | Verify how the reference app is opened or imported in the AI App Builder. |
| 6 | Content source | Keep journey content as JSON in the package, or generate it from this documentation site to avoid duplication. |
Readiness Checklist
Per training system:
- [ ]
Empower – Companiondeployed from the Catalog, after the vertical packages - [ ] Companion opens through
/auth/?url=%2Fpublic%2Fempower-companion%2Findex.htmlfor every participant account - [ ] Training Event created with the summary recipient (
jarne.vynckier@skyline.be) and trainer group - [ ] J4 backend check is green for every deployed vertical
- [ ] Test upload: an app built with the AI App Builder publishes and opens through the returned link
- [ ] Reference apps publish and open for the verticals of this event
- [ ] Test submission: the summary document arrives at
jarne.vynckier@skyline.bewith the expected front matter - [ ] Trainer view shows all participants