Supporting design and implementation documentation for the Console + RPS Cloud Deployment ADR (deployment#614).

• Abstract
• Console + RPS observations
  • Local activation
  • Remote activation
• Reference flows
• Other Design Decisions
• Diagrams
  • Cloud deployment
  • Component map
  • Inter-service communication
  • Database layouts
  • Microservice roles and responsibilities
  • Activation flow
• Detailed design by decision
  • 1 Console owns profiles, RPS orchestrates provisioning
  • 2 RPS supports both deployments
  • 3 One database, shared Vault
  • 4 Device API compatibility
  • 5 Trust boundary
  • 6 Migration from MPS + RPS
  • 7 Deployment profiles and provider selection
  • 8 Console scaling and device affinity
• Review feedback
  • Deployment profiles
  • Greenfield and brownfield differ only at first start
  • Differences from the current implementation
  • Vault paths Console and RPS must agree on
  • Certificate reuse is the brownfield precondition
  • API additions accepted as Console scope
  • Changes the ADR body needs
  • Proposed diagrams

A cloud deployment of Console and RPS runs both services side by side, with Console in place of MPS. RPS stays the provisioning orchestrator, and Console supports the RPS activation flow by serving device lifecycle APIs and managing devices once provisioned. This design proposes that Console owns profiles and the only database, including device and profile passwords; RPS reads the configuration it needs at activation from Console's API, with its own REST APIs turned off; Console upserts devices and auth stays at the gateway. Vault holds only the CIRA TLS identity (MPSCerts) and Console's app encryption key, not passwords. RPS supports both deployments, MPS + RPS as it works today and Console + RPS.

Observations and what breaks when Console and RPS run together, without the decisions in this ADR.

Deployed the stack with make up, which brings up console, rps, db, vault, kong and webui. Local activation with Console works.

Remote mode, orchestrated by RPS. Every problem below is in this path.

Note: All fixes and workarounds are temporary, done only to reach the next blocker.

Baseline Cloud v2 (MPS + RPS) is unchanged; refer to the architecture reference: cloud deployment, component map, inter-service communication, database layout, service roles, and activation phases. The Console + RPS proposal diagrams under the design decisions adapt these references, with Console in place of MPS and MPS Router.

These are proposals for review, not settled decisions.

1. Migration from MPS + RPS to Console + RPS must be planned. Propose an explicit, repeatable migration for device inventory and configuration, moving device and profile passwords from Vault into Console's database and carrying MPSCerts into Vault unchanged, with verification and rollback. See 6.

2. Support three deployment profiles with standalone defaults. Standalone Console, Cloud greenfield, and Cloud brownfield all keep passwords in Console's database, and select a Vault-backed provider for the CIRA certificate and the app encryption key. Leaving the settings unset preserves standalone behavior. See 7.

3. Console is single-instance for v3.0. Horizontal CIRA scaling and MPS Router device affinity are not replaced in this release; this is a documented regression from Cloud v2 and a follow-up requirement before scaling Console horizontally. See 8.

These diagrams adapt the architecture reference to the Console + RPS proposal, with Console in place of MPS and MPS Router. RPS reads configuration from Console's API; Vault holds only MPSCerts and the app encryption key, not passwords.

flowchart TB
   Cloud["Console + RPS cloud deployment (proposal)"]
   Cloud --> Console["Console"]
   Cloud --> RPS["RPS"]
   Cloud --> RPC["RPC-Go"]
   Cloud --> SWUI["Sample Web UI"]
   Cloud --> EA["Enterprise Assistant"]
   SWUI --> UITAngular["UI Toolkit Angular"]
   UITAngular --> UIT["UI Toolkit"]
   Console --> GoWSMAN["Go-WSMAN-Messages"]
   RPS --> WSMAN["WSMAN-Messages"]
   RPC --> GoWSMAN

graph TB
   subgraph External["External Network"]
      Client[API Client / Browser]
   end
   subgraph Device["Client Machine (vPro/ISM)"]
      RPC["RPC-Go<br/>(OS Layer)"]
      AMT["Intel AMT<br/>(Firmware Layer)"]
   end
   subgraph Cloud["Cloud Services"]
      Kong["Kong API Gateway<br/>:443 HTTPS<br/>JWT · CORS · TLS termination"]
      subgraph Core["Core Services - internal network only, never published to the host"]
         Console["Console, single instance<br/>:8181 REST API + WS Relay<br/>:4433 CIRA (TLS+APF)"]
         RPS["RPS<br/>:8080 WebSocket (activation)<br/>config API off (RPS_MODE=console)"]
      end
      subgraph Backing["Backing Services (3rd Party)"]
         DB["Console database :5432<br/>devices, configuration, passwords"]
         Vault["Vault :8200<br/>MPSCerts · app encryption key"]
      end
      WebUI["Sample Web UI<br/>nginx :80"]
   end
   RPC -->|"LMS (APF) :16992/16993"| AMT
   Client -->|HTTPS :443| Kong
   RPC -->|"WSS :443 /activate"| Kong
   AMT -->|"TLS :4433 (CIRA)"| Kong
   Kong -->|"/api, /api/v1/authorize, /relay"| Console
   Kong -->|"/activate, /deactivate, /maintenance"| RPS
   Kong -->|/| WebUI
   Kong -->|":4433 TCP passthrough"| Console
   RPS -->|"POST /api/v1/devices, upsert, including device credentials"| Console
   RPS -->|"configuration reads"| Console
   Console --> DB
   Console -->|"read MPSCerts and the app encryption key"| Vault

   style Console fill:#1565C0,color:#fff
   style RPS fill:#1976D2,color:#fff
   style WebUI fill:#2196F3,color:#fff
   style RPC fill:#42A5F5,color:#fff
   style Kong fill:#616161,color:#fff
   style DB fill:#616161,color:#fff
   style Vault fill:#616161,color:#fff
   style Client fill:#616161,color:#fff
   style AMT fill:#616161,color:#fff
   style Device fill:#EEEEEE,color:#000
   style Cloud fill:#ffffff,color:#000,stroke:#1565C0
   style Core fill:#E3F2FD,color:#000
   style Backing fill:#FAFAFA,color:#000
   style External fill:#FAFAFA,color:#000

graph LR
   Client[Client / Browser] -->|":443 HTTPS"| Kong
   RPC[RPC-Go] -.->|":443 WSS /activate"| Kong
   AMT[Intel AMT] ==>|":4433 TLS (CIRA)"| Kong

   Kong -->|":8181 HTTP auth / API / WS relay"| Console
   Kong -->|":8080 WS /activate, /deactivate, /maintenance"| RPS
   Kong -->|":80 HTTP"| WebUI[Sample Web UI]
   Kong ==>|":4433 TCP passthrough"| Console
   RPS -->|"configuration reads, device credential writes :8181"| Console
   Console --> CDB[(Console database<br/>devices, configuration, passwords)]
   Console -->|"read MPSCerts and the app encryption key"| Vault[Vault :8200]

   style Console fill:#1565C0,color:#fff
   style RPS fill:#1976D2,color:#fff
   style WebUI fill:#2196F3,color:#fff
   style RPC fill:#42A5F5,color:#fff
   style Kong fill:#616161,color:#fff
   style CDB fill:#616161,color:#fff
   style Vault fill:#616161,color:#fff
   style Client fill:#616161,color:#fff
   style AMT fill:#616161,color:#fff

RPS reads configuration through Console's API and does not connect to a database or to Vault directly.

Standalone Console, Cloud v2 MPS + RPS, and Console + RPS are three separate deployment profiles; RPS_MODE selects the RPS deployment per decision 2.

flowchart TB
   subgraph SA["Standalone Console"]
      ConsoleSA[Console] --> SADB[("Console database<br/>devices, configuration,<br/>secrets encrypted in columns")]
   end
   subgraph V2["Cloud v2, MPS + RPS, the brownfield source"]
      MPS2[MPS] --> MPSDB[("mpsdb<br/>devices")]
      RPS2[RPS] --> RPSDB[("rpsdb<br/>configuration")]
      MPS2 --- V2Vault[("Vault<br/>MPSCerts, devices/guid,<br/>profile secrets")]
      RPS2 --- V2Vault
   end
   subgraph CP["Console + RPS cloud, greenfield and brownfield"]
      ConsoleC[Console] --> CDB[("Console database<br/>devices, configuration,<br/>passwords encrypted in columns")]
      RPSC[RPS] -. "configuration API, device credential writes" .-> ConsoleC
      ConsoleC --- CVault[("Vault<br/>MPSCerts, app encryption key")]
   end
   V2 -. "migrate records; passwords move from Vault into the database" .-> CP

Propose migrating device inventory from mpsdb and RPS-owned configuration from rpsdb into Console-owned storage, and migrating device and profile passwords out of Vault's devices/{guid} and profiles/{name} into Console's database columns. Do not treat the legacy database schemas as interchangeable or mount both services on one unconverted schema.

graph LR
   RPS["RPS<br/>activation · deactivation · maintenance<br/>profile application · device registration"]
   Console["Console<br/>devices · AMT operations · CIRA/APF listener<br/>profiles and all configuration · login"]
   CDB[("Console database")]
   Vault[("Vault")]
   RPS -->|"POST /api/v1/devices, upsert, including device credentials"| Console
   RPS -->|"configuration over Console's API"| Console
   Console --> CDB
   Console -->|"read MPSCerts and the app encryption key"| Vault
   style RPS fill:#1976D2,color:#fff
   style Console fill:#1565C0,color:#fff

sequenceDiagram
   participant Admin
   participant UI as Sample Web UI
   participant Kong
   participant Console
   participant DB as Console database
   participant RPS
   participant Vault
   participant RPC as RPC-Go
   participant AMT

   Console->>Vault: Read existing MPSCerts and the app encryption key at startup
   Vault-->>Console: Existing MPS root, server TLS material, and app encryption key
   Console->>Console: Start the CIRA listener on 4433
   Note over Console: Fail startup if MPSCerts is missing or unreadable, never generate a replacement

   Admin->>UI: Create profile and related configuration
   UI->>Kong: Authenticated Console API request
   Kong->>Console: Profile/configuration write
   Console->>DB: Store profile/configuration, including AMT_PASSWORD and MEBX_PASSWORD
   RPC->>Kong: WSS /activate
   Kong->>RPS: Activation request
   RPS->>Console: Read profile/configuration over Console's API
   RPS->>RPC: Send WSMAN request
   RPC->>AMT: Forward via LMS/MEI
   AMT-->>RPC: WSMAN response
   RPC-->>RPS: Relay response
   Note over RPS,AMT: CIRA configuration installs the MPS root into AMT's trusted store
   RPS->>Console: Write device credentials (POST/PATCH /api/v1/devices)
   Console->>DB: Store device credentials
   loop Registration, CIRA registration (when enabled), and provisioning status
      RPS->>Console: POST /api/v1/devices
      Console->>DB: Insert or merge by GUID
   end
   AMT->>Kong: Outbound CIRA TLS + APF connection
   Kong->>Console: TCP passthrough to CIRA listener
   Console-->>AMT: Present server certificate from MPSCerts
   AMT->>AMT: Validate against MPS root installed at activation
   Console->>DB: Read device record and MPS_PASSWORD for APF authentication
   Console-->>AMT: APF authentication succeeds

RPS remains the activation orchestrator. Console owns the device record and CIRA/APF endpoint in this proposal. RPS writes device credentials through Console's API; Console reads and writes all passwords in its own database, and uses Vault only for MPSCerts and the app encryption key.

RPS keeps activation, deactivation and maintenance. No change to the RPS state machines. In Docker, mps_server is set as RPS_MPS_SERVER=http://console:8181.

Ownership split

RPS still exposes the same CRUD on its own API, so it must be turned off. RPS's configuration API is withdrawn in this deployment, not reproduced by Console; ISVs move to Console's API, with a field mapping for profile tags, wireless link policy, the proxy model, and domain lookup by suffix.

Proposal: add RPS_MODE, mps by default, console in this deployment. This is a change in RPS source and ships in an RPS release. No deployment configuration substitutes for it: RPS mounts its routes in its own code, so the setting has to exist there. The config key is mode - rc strips the rps_ prefix off env vars, the same way RPS_MPS_SERVER sets mps_server.

RPS reads configuration from Console's API

With RPS_MODE=console, RPS's configuration CRUD routes under /api/v1 are turned off; the health route remains. RPS selects the Console API provider and keeps no database connection of its own. We propose retaining RPS's health route and probing Console /healthz at startup.

Reads from Console

RPS's configuration reads move to Console's API, behind the existing IDB read methods so the state machines are unchanged. Each read is tenant scoped.

Four gaps in that read path:

mps stays the default, so existing deployments are unchanged.

We need one Console-owned database and no RPS database connection. We propose consoledb as its name; renaming the existing rpsdb is a separate migration operation. RPS needs no database: all of its tables are configuration and it keeps no device or runtime state, so its connection string is dropped. It must not read Console's database either.

Console's database holds device and profile passwords (AMT_PASSWORD, MPS_PASSWORD, MEBX_PASSWORD), as it does for standalone Console today. RPS writes and reads device credentials through Console's device API rather than Vault, removing the Vault round trip this used to require; Vault API calls are costly, and passwords are read far more often than certificates.

RPS and MPS already share one Vault; Console keeps using it, narrowed to the CIRA TLS identity (MPSCerts) and Console's APP_ENCRYPTION_KEY. For brownfield deployments, Console must read the existing MPSCerts in place rather than seeding it from Console's root certificate. The certificate approach is not finalized; see decision 3 in the ADR.

Requirements:

Console must serve the endpoints RPS calls, and persist status, activatedAt and lastProvisionedAt in deviceInfo:

• GET /api/v1/devices/{guid}?tenantId=...
• POST /api/v1/devices
• PATCH /api/v1/devices
• DELETE /api/v1/devices/{guid}?tenantId=...
• DELETE /api/v1/devices/refresh/{guid}?tenantId=...

The contract change is upsert: a POST for a GUID that already exists must update that row instead of failing. MPS behaves this way; Console returns 409. RPS posts the same device more than once per activation - registration and provisioning status always, plus CIRA registration with mpsusername on the CIRA path - so a 409 on any of them fails provisioning.

Proposal: on GUID conflict, POST merges the supplied fields the same way PATCH does. 201 stays "created", 200 means "merged". A caller can then overwrite mpsusername, hostname or tags on an existing device; the control against that is the trust boundary in 5.

If duplicate POSTs may run concurrently, we propose serializing merges by GUID or making the merge atomic to avoid lost field updates.

DELETE /api/v1/devices/refresh/{guid} is called after an AMT password change. Console caches a WSMAN connection per GUID, and without this route it keeps using the old password. Console reads device credentials from its own database at the point of use rather than caching its own copy, so RPS must write the rotated password through Console's device API before calling this route; refreshing first re-caches the old value.

The proposal keeps the Cloud 2.x pattern of gateway-enforced authentication, but the unauthenticated surface behind the gateway is wider than 2.x: RPS now also reads Console's configuration over that same path, not only device operations.

Proposal: a Console auth mode, auth.gatewayEnforced (AUTH_GATEWAY_ENFORCED), used with AUTH_DISABLED=false. It changes one thing: /api is mounted without Console's JWT middleware. Login still checks credentials and signs the JWT and session cookie Kong verifies, the relay token is still signed per device and checked by Console, and a JWT key is still required. Console refuses to start with both disabled and gatewayEnforced set. Tenant comes from the x-tenant-id header and is unaffected.

This is a deployment requirement, not only an assumption: 8181 is only on the internal Compose network, never published to the host.

Known gaps, bounded by that requirement:

• RPS→Console is unauthenticated. Any caller on the internal network can register, merge or delete a device, or drive AMT operations, indistinguishably from RPS. Closing this needs a service token or mTLS between RPS and Console - an RPS change, deferred to a future release (proposed v3.1), out of scope for v3.0.
• The configuration reads run on the same path. Per 1 RPS reads profiles, wireless, 802.1x and domain configs over that same unauthenticated API.

Moving to Console + RPS requires a data migration, not only a Compose or routing change. MPS owns device inventory in mpsdb; RPS owns profiles and provisioning configuration in rpsdb; Vault holds device and configuration passwords today. The migration must preserve tenant ownership and references while avoiding a shared, incompatible database schema.

Open decisions: whether migration is online or requires downtime; which historical fields and records are in scope; how secrets and encrypted database fields are converted; whether the importer is one-time or rerunnable; and the supported rollback window and data-loss objective.

Proposal: provide a repeatable migration/export-import procedure with a pre-migration backup, write freeze, validation, cutover, and rollback. The migration must move passwords out of Vault into Console's database, and move the source configuration data into Console-owned storage, before Console becomes the source of truth.

Proposed migration sequence:

1. Inventory source databases, Vault paths, service versions, tenant mappings, and unsupported configuration; take restorable database and Vault backups.
2. Freeze configuration and device-inventory writes, then export records and transform them into Console's schema using a repeatable importer or supported Console APIs. Do not point both services at the legacy shared schema.
3. Preserve MPSCerts in Vault unchanged, and adopt or provision APP_ENCRYPTION_KEY there; migrate device and profile passwords from Vault into Console's database, verifying by read checks without logging their values. Do not rotate or regenerate the MPS root during brownfield cutover.
4. Validate record counts, GUID uniqueness, tenant assignments, profile references, device metadata, certificate-chain continuity, and representative credential lookups before switching traffic.
5. Switch the gateway/UI and RPS configuration provider during a planned cutover. Keep legacy databases and services read-only until the new deployment is accepted.
6. Define rollback to the pre-cutover services and data snapshots, including how to handle writes made after cutover so rollback does not lose or split-brain data.

Console supports three deployment profiles. Passwords always live in Console's database; the CIRA certificate source and the app-encryption-key source are the startup selections, and their defaults preserve the existing standalone installation.

Proposal: unset provider settings mean standalone behavior. Cloud deployments must explicitly select Vault-backed CIRA certificates and a Vault-backed app encryption key; passwords stay in the database in every profile. Console must validate the selected provider at startup; in Vault certificate mode, missing or unreadable MPSCerts is fatal. It must not fall back to local certificate files or a newly generated identity.

Greenfield and brownfield use the same runtime profile after startup. They differ only in the deployment bootstrap: greenfield provisions the CIRA identity once before Console starts; brownfield retains the existing MPS identity and its existing Vault paths, and migrates its Vault passwords into Console's database.

Decision for v3.0: Console is deployed as a single instance. The CIRA listener keeps active connections in process, and this proposal does not replace MPS Router's mpsinstance-based device affinity. Horizontal Console scaling is unsupported in this release; devices must reconnect after an instance restart. This is a regression from Cloud v2's horizontally routed MPS tier and must be resolved before Console is scaled horizontally. The migrated mpsinstance value is not a routing mechanism in Console mode.

Architecture-level feedback from reviewing this proposal against the Cloud v2 architecture reference and the current Console and RPS sources.

Scope reviewed: the end-state where Console owns every REST API, including the configuration APIs RPS serves in v2, and Console's database owns all the data behind them. RPS is then an activation, deactivation and maintenance orchestrator with no REST surface and no database.

The direction proposed is that Console adapts: it works with the single database, the shared Vault and the missing APIs, while the standalone on-premises deployment continues to work unchanged. The differences this rests on are recorded in differences from the current implementation.

Code references are permalinks pinned to Console 46b1d54 and RPS b797117, both on main, so the line numbers stay valid as the branches move.

Console has to serve three deployments from one codebase. Most of the feedback above applies to the two cloud profiles. The standalone profile is a constraint on the solution, not a target of it.

Proposal: Console adopts the single database and shared Vault for the cloud profiles, and adds the missing APIs, behind two selectable providers whose defaults reproduce standalone behaviour exactly.

This is not a new idea for Console. The choice between Vault and the database is already in the code, just made in the wrong place:

• Domains. Fetches the certificate from Vault when a certificate store is configured and the database column is empty, and carries on with whatever the database held when it is not (domains/usecase.go L140-L152).
• Profile export. Tries to decrypt the domain's provisioning certificate password, and treats a failed decryption as "this one came from Vault as plaintext" (profiles/usecase.go L231-L238).

Each read site decides for itself, so the answer can differ from one to the next, and nothing states what the deployment as a whole is doing.

Proposal: make it one choice, read once at startup, and apply it everywhere. Individual read sites stop deciding.

Three rules keep the standalone deployment safe:

1. Standalone is the default. A deployment that sets nothing new behaves exactly as it does today: secrets encrypted into Console's database (devices/usecase.go L114-L128), certificates read from local files (app.go L220-L223). Nobody has to change a standalone install.
2. Never mix the two. A deployment reads its secrets from Vault or from the database, never from both. The either/or fallbacks in the code today are there to help migration; they are not a way to run.
3. Fail loudly, not quietly. In Vault mode, Console does not quietly fall back to the database if Vault is unreachable, and does not quietly generate a certificate if MPSCerts is missing. It refuses to start.

Rule 3 matters most at cutover. Without it, one wrong Vault setting gives a Console that looks healthy, turns away every device that tries to authenticate, and offers a certificate no device recognises. The deployment appears to work and manages nothing. With rule 3, it stops at startup and says why.

Once running, the two cloud profiles are the same deployment. They differ in what already exists when Console first starts, which is what decision 6 has to cover.

Nothing in the brownfield column requires a code path the greenfield profile does not also use. The migration is a data and ordering problem, not a second implementation.

Secrets stay where they are throughout. Because both cloud profiles read Vault, decision 6's "keep device credentials at devices/{guid}" is accurate as written: the migration moves device records, not device secrets, and nothing has to decrypt and re-encrypt a credential on the way.

The baseline the proposal rests on: what v2 does today, and where Console differs. Split by whether the proposal answers the difference or leaves it open.

Addressed by this proposal

Gaps this proposal does not yet answer

Selecting the Vault provider is not enough on its own. Console and RPS have to use the same paths, and today they do not.

Decision 3 requirement 5 proposes seeding MPSCerts from Console's root certificate. For existing deployments this is reversed, and it is the single item that decides whether migrated devices reconnect at all. The MPS root is load-bearing in two places on the firmware side:

1. CIRA trust. RPS installed the MPS root into AMT's trusted root store with AddTrustedRootCertificate at activation. Console's CIRA listener must present a leaf chaining to that same root, or the TLS handshake fails permanently. AMT does not retry its way out of a trust failure.
2. The E2E TLS device leaf. Each device certificate at devices/{guid}/TLS_ISSUED_CERTIFICATE was signed by the MPS root private key, and AMT holds the matching private key internally. It cannot be reissued without re-running GenerateKeyPair and AddCertificate on the device.

Proposal: replace requirement 5 with an in-place read. Console reads the existing MPS root and server TLS material from MPSCerts unchanged; it neither generates a root nor relocates the existing one. A Console deployment that cannot read MPSCerts must fail to start rather than fall back to generating a self-signed set, because that fallback turns a Vault misconfiguration at cutover into a silent loss of every migrated device.

The missing APIs are Console's to add. Each is additive, so none of them changes standalone behaviour: a standalone deployment gains endpoints and an entity it need not use.

Two questions to settle alongside them:

• Do Console's APIs match RPS's? ISVs build against the RPS REST API today, and the toolkit documentation tells them to. If the request and response shapes differ, this is a breaking change and has to be called one. RPS serves proxy CRUD that Console has no entity for (proxy/index.ts L18-L22), and Console has the domain-by-suffix lookup as a usecase with no route behind it (domains/usecase.go L98).
• Who updates Console's copy of the AMT password? RPS changes the password during maintenance and writes it to devices/{guid} in Vault (changePassword.ts L102-L107), while Console keeps its own encrypted copy (devices/usecase.go L114-L128). The refresh route in decision 4 does not exist in Console yet; once added it would only drop the cached connection, so a stale stored copy is read again.

Proposal: adapt Console in both cases, and leave RPS's behaviour as it is.

One ordering requirement follows from adaptation 2: RPS must write the new password to Vault before it calls the refresh route. Refreshing first makes Console re-read and re-cache the old value.

The review above is written as feedback. These are the edits to the decisions themselves, where the current text states something the code contradicts or a position it does not yet take. Rows 1 to 6 are the decision text; rows 7 to 12 are the diagrams.

Two verification tasks come with them, neither of which is an edit:

• Confirm device GUID uniqueness is global rather than per-tenant, before migration merges tenants into one database.
• Add standalone-profile regression coverage to CI, so adopting the shared Vault and single database does not regress the on-premises deployment.

Replacements for the four diagrams rows 7 to 12 refer to. Each carries the same information as the original plus the missing parts.

Red marks what is new or changed relative to the diagram it replaces. Everything in the original styling is unchanged. The red is a review aid; drop it once the diagrams are adopted.

Microservice roles - fixes row 7, where option 2's read is drawn into Console instead of the database, and labels the Vault edges from row 9.

graph LR
   RPS["RPS<br/>activation · deactivation · maintenance<br/>profile application · device registration"]
   Console["Console<br/>devices · AMT operations · CIRA/APF listener<br/>profiles and all configuration · login"]
   CDB[("Console database")]
   Vault[("Vault")]
   RPS -->|"POST /api/v1/devices, upsert"| Console
   RPS -. "option 1, configuration over Console's API" .-> Console
   RPS -. "option 2, configuration direct from the database" .-> CDB
   Console --> CDB
   RPS -->|"write devices/{guid}, read profile secrets"| Vault
   Console -->|"read MPSCerts and devices/{guid}, write profile secrets"| Vault

   style RPS fill:#1976D2,color:#fff
   style Console fill:#1565C0,color:#fff
   %% new nodes
   style CDB fill:#C62828,color:#fff
   style Vault fill:#C62828,color:#fff
   %% new edges: option 2 to the database, and the Vault reads and writes
   linkStyle 2,3,4,5 stroke:#C62828,stroke-width:2px

Component map - adds the single-instance CIRA listener and the internal-only boundary from row 12, and the labelled Vault edges from row 9.

graph TB
   subgraph External["External Network"]
      Client[API Client / Browser]
   end
   subgraph Device["Client Machine (vPro/ISM)"]
      RPC["RPC-Go<br/>(OS Layer)"]
      AMT["Intel AMT<br/>(Firmware Layer)"]
   end
   subgraph Cloud["Cloud Services"]
      Kong["Kong API Gateway<br/>:443 HTTPS<br/>JWT · CORS · TLS termination"]
      subgraph Core["Core Services - internal network only, never published to the host"]
         Console["Console, single instance<br/>:8181 REST API + WS Relay<br/>:4433 CIRA (TLS+APF)<br/>connections held in process"]
         RPS["RPS<br/>:8080 WebSocket (activation)<br/>config API off (RPS_MODE=console)"]
      end
      subgraph Backing["Backing Services (3rd Party)"]
         DB["Console database :5432"]
         Vault["Vault :8200<br/>MPSCerts · devices/guid · profile secrets"]
      end
      WebUI["Sample Web UI<br/>nginx :80"]
   end
   RPC -->|"LMS (APF) :16992/16993"| AMT
   Client -->|HTTPS :443| Kong
   RPC -->|"WSS :443 /activate"| Kong
   AMT -->|"TLS :4433 (CIRA)"| Kong
   Kong -->|"/api, /api/v1/authorize, /relay"| Console
   Kong -->|"/activate, /deactivate, /maintenance"| RPS
   Kong -->|/| WebUI
   Kong -->|":4433 TCP passthrough"| Console
   RPS -->|"POST /api/v1/devices, upsert"| Console
   RPS -. "option 1, configuration API" .-> Console
   RPS -. "option 2, direct DB and schema compatibility required" .-> DB
   Console --> DB
   Console -->|"read MPSCerts for the CIRA listener"| Vault
   Console -->|"read devices/{guid}, write profile secrets"| Vault
   RPS -->|"write devices/{guid}, read profile secrets"| Vault

   style Console fill:#1565C0,color:#fff,stroke:#C62828,stroke-width:3px
   style RPS fill:#1976D2,color:#fff
   style WebUI fill:#2196F3,color:#fff
   style RPC fill:#42A5F5,color:#fff
   style Kong fill:#616161,color:#fff
   style DB fill:#616161,color:#fff
   style Vault fill:#616161,color:#fff,stroke:#C62828,stroke-width:3px
   style Client fill:#616161,color:#fff
   style AMT fill:#616161,color:#fff
   style Device fill:#EEEEEE,color:#000
   style Cloud fill:#ffffff,color:#000,stroke:#1565C0
   style Core fill:#E3F2FD,color:#000,stroke:#C62828,stroke-width:3px
   style Backing fill:#FAFAFA,color:#000
   style External fill:#FAFAFA,color:#000
   %% new edges: the three labelled Vault paths
   linkStyle 12,13,14 stroke:#C62828,stroke-width:2px

Red outlines mark the three changed labels: the Core subgraph gains the internal-only boundary, Console gains the single-instance note, and Vault names what it holds.

Activation flow - adds the certificate path from row 8 and the repeated registration from row 10.

sequenceDiagram
   autonumber
   participant Admin
   participant Kong
   participant Console
   participant DB as Console database
   participant RPS
   participant Vault
   participant RPC as RPC-Go
   participant AMT

   rect rgb(255, 235, 238)
      Note over Console,Vault: New. Startup. Console refuses to start if MPSCerts is missing.
      Console->>Vault: Read MPSCerts, root and server certificate
      Vault-->>Console: Certificate material, read in place
      Console->>Console: Start the CIRA listener on 4433
   end

   Admin->>Kong: Create profile and related configuration
   Kong->>Console: Authenticated Console API request
   Console->>DB: Store profile/configuration
   Console->>Vault: Store profile secrets at the paths RPS reads

   RPC->>Kong: WSS /activate
   Kong->>RPS: Activation request
   RPS->>Console: Read profile/configuration (option 1 API, option 2 database)
   RPS->>Vault: Read profile secrets

   loop WSMAN round-trips
      RPS->>RPC: WSMAN request
      RPC->>AMT: Forward via LMS/MEI
      AMT-->>RPC: WSMAN response
      RPC-->>RPS: Relay response
   end

   rect rgb(255, 235, 238)
      Note over RPS,AMT: New. CIRA configuration installs the MPS root into AMT's trusted store.
   end

   RPS->>Vault: Write device credentials at devices/{guid}

   rect rgb(255, 235, 238)
      Note over RPS,DB: New. Drawn once before, which hid the upsert requirement.
      loop Registration, CIRA registration and provisioning status
         RPS->>Console: POST /api/v1/devices
         Console->>DB: Insert, or merge when the GUID already exists
      end
   end

   rect rgb(255, 235, 238)
      Note over Console,AMT: New. The certificate path brownfield reconnection depends on.
      AMT->>Kong: TLS ClientHello on 4433
      Kong->>Console: TCP passthrough to the CIRA listener
      Console-->>AMT: Server certificate from MPSCerts
      AMT->>AMT: Validate against the MPS root installed at activation
      AMT->>Console: APF USERAUTH_REQUEST
   end

   Console->>DB: Read device record for MPSUsername
   Console->>Vault: Read MPS_PASSWORD at devices/{guid}
   Console-->>AMT: APF USERAUTH_SUCCESS

Red-tinted blocks are new. The unshaded steps are carried over from the existing activation flow.

Database layouts - fixes row 11 by drawing all three, including the v2 layout the brownfield migration reads from.

flowchart TB
   subgraph SA["Standalone Console"]
      ConsoleSA[Console] --> SADB[("Console database<br/>devices, configuration,<br/>secrets encrypted in columns")]
   end
   subgraph V2["Cloud v2, MPS + RPS, the brownfield source"]
      MPS2[MPS] --> MPSDB[("mpsdb<br/>devices")]
      RPS2[RPS] --> RPSDB[("rpsdb<br/>configuration")]
      MPS2 --- V2Vault[("Vault<br/>MPSCerts, devices/guid,<br/>profile secrets")]
      RPS2 --- V2Vault
   end
   subgraph CP["Console + RPS cloud, greenfield and brownfield"]
      ConsoleC[Console] --> CDB[("Console database<br/>devices and configuration")]
      RPSC[RPS] -. "option 1, configuration API" .-> ConsoleC
      RPSC -. "option 2, direct DB" .-> CDB
      ConsoleC --- CVault[("Vault<br/>MPSCerts, devices/guid,<br/>profile secrets")]
      RPSC --- CVault
   end
   V2 -. "migrate records, secrets stay in Vault" .-> CP

   %% new: the standalone and v2 layouts, and the migration edge
   style SA fill:#FFEBEE,color:#000,stroke:#C62828,stroke-width:3px
   style V2 fill:#FFEBEE,color:#000,stroke:#C62828,stroke-width:3px
   linkStyle 10 stroke:#C62828,stroke-width:2px

The existing diagram drew only the Console + RPS layout. The two red subgraphs and the migration edge are new.

The recommendation of option 1 over option 2 in decision 1 is unaffected by the above, and observation 2 in the problem table remains the strongest argument for it: a missing relation in RPS's unversioned schema surfaced to the device as profile-not-found.