# DBAOps Sovereign™

**Team Instructions — Path to Shippable**

> **May 2026 — Living discovery:** Counts and gate summaries in this document reflect discovery snapshots from the repo. For **current** numbers, use the latest output under [`_discovery/`](../_discovery/) (open the newest timestamped folder and read `summary.md` / `findings.*`).
>
> **Stale static figures:** `Discover-DBAOpsSovereign.ps1` now accounts for `globalApiAuth`, and **bcrypt hashes were removed from literals in the mock DB**—so Section 3.1 items such as “97 unauthenticated routes” and “3 hardcoded bcrypt hashes” may be **out of date** relative to older static scans. **Re-run `Discover-DBAOpsSovereign.ps1`** after you pull changes.
>
> **Related docs:** [`ENGINEERING-HANDOFF-STATUS.md`](ENGINEERING-HANDOFF-STATUS.md) (manual vs codebase), [`CUSTOMER-DEPLOYMENT.md`](CUSTOMER-DEPLOYMENT.md) (production deployment), and the repo root [`README.md`](../README.md) (overview and quick start).

**Companion directive to the Engineering Handoff Manual**  
**Grounded in discovery findings from the actual codebase and repository database**  
**For the team building the shippable product**  
**serving every targeted industry under one license-driven binary**  
**Rhoylle Innovation Empire LLC**  
**DBAOps™ Serial No. 99717776 · May 2026**

## 1. Read this first

You have been handed three things: the codebase at K:\RHOYLLE BUSINESS EMPIRE LLC\Business Plans\PRODUCTS\DBAOps-Sovereign\, the Engineering Handoff Manual, and this Team Instructions document. The manual tells you what to build. This document tells you what to focus on, in what order, this month and next. Read the manual first, then come back here.

The product is closer to shippable than its current state suggests. The architecture is real, the schema is substantial (177 tables, 108 intact foreign keys), the route surface is large (405 routes, 78 React pages), and the middleware needed for licensing, authentication, and tenant isolation already exists as files in the codebase. What is missing is the wiring, the data pipeline, and a handful of hygiene practices that any paying customer in the industries we target would consider table stakes.

Critical context: The product was discovered to have an empty pilot fleet table, no database backups, three hardcoded credential accounts deployed to the live repository, and 97 unauthenticated routes including two that accept writes. None of these are unusual for a pre-pilot product. All of them must be fixed before any paying customer of any industry sees the system. Section 3 lists each one and what to do.

**Your single sentence of purpose:** take a working but unfinished prototype and turn it into a license-driven product that an auditor in any of the eight target industries can defend, a board can present from, and a paying customer can trust with their fleet.

## 2. The product position you own now

Before any decision, internalize what this product is — and what it is not. Misunderstanding this is the single biggest risk to the project.

### 2.1 Sovereign serves every target industry from one binary

There are no separate builds for Government, Banking, Healthcare, or Commercial. There is one source tree, one binary, one deployment shape. The License Manifest decides what each customer sees and can do. A bank gets PCI-DSS and SOX packs enabled; a defense contractor gets ITAR and CJIS plus locked policies; a community user gets read-only browsing and three monitored instances. Same binary in all cases.

**Hard rule:** You will not introduce edition-specific code branches. Any pull request that reads "if edition == Government" or its equivalent is rejected before review. The manifest decides behavior; the code applies the manifest. This is non-negotiable.

### 2.2 Four commitments that constrain every decision

These are not features. They are constraints. Every line of code is checkable against them. If a feature would compromise any of these, stop and escalate.

- **Absolute data sovereignty.** No customer telemetry, configuration, or operational data ever leaves the customer environment by default. No phone-home for analytics. AI runs locally via ONNX Runtime.
- **Truthfulness of every metric.** The product never presents an absence of data as a positive answer. A KPI showing "zero failed backups" must be distinguishable from "we have not collected backup data." Every metric carries collection state, data-as-of timestamp, and degraded flag.
- **Court-admissible audit chain.** Every action, read, write, configuration change, and remediation appends to a cryptographic hash chain. Merkle proofs computed on a schedule. Evidence packages signed with customer-owned keys, verifiable by a third party.
- **Air-gapped operation.** Runs with no internet, no DNS, no outbound traffic. Automated test asserts this. Required by default for the Government and Defense tiers.

## 3. What discovery actually found in your codebase

Before you write a line of code, study these findings. They are the ground truth as of the handoff. Every one of them shapes a decision you will make in your first month.

### 3.1 The numbers

| Area | Value | What it means |
|------|-------|---------------|
| API routes total | 405 | Substantial surface. Larger than typical v1. |
| Unauthenticated routes | 97 | Security failing. Mechanical fix but mandatory. |
| Unauthenticated writes | 2 | Highest priority. Find these two today. |
| Routes with featureGate | 76 of 405 (18.8%) | License enforcement nowhere near complete. |
| Middleware files available | 14 | Architecture is right. Wiring is missing. |
| React pages | 78 | Extensive UI surface. |
| SQL tables | 177 | Schema scope is substantial. |
| Foreign keys (all intact) | 108 | Schema relationships are sound. |
| Tables with data | 33 | Reference catalogs seeded, ops data not. |
| Empty fact tables | 11 | Truthfulness gate failing. No data to display. |
| Hardcoded bcrypt hashes in source | 3 | Default accounts in db.js, deployed live. |
| Hardcoded threshold patterns | 100 | Configuration Catalog migration scope. |
| Pilot fleet servers registered | 0 | Gone. Wiped by May 15 migration. No backup. |
| Database backups taken | 0 | SovereignRepository has never been backed up. |

### 3.2 The asset hiding in FuturisticREPO

Discovery found a second database on the same SQL instance: FuturisticREPO, 72 tables, last touched March 9. This is a dormant earlier prototype. It has cleaner architectural decompositions in four schemas that the handoff manual specifically calls Sovereign to add:

| FuturisticREPO schema | Tables | Why it matters to you |
|-----------------------|--------|------------------------|
| licensing | 6 tables (Products, ProductSkus, Licenses, Entitlements, Trials, UsageMeters) | Adopt this decomposition for the License Manifest work. Do not reinvent. |
| iam | 5 tables (Users, Roles, Permissions, RolePermissions, UserRoles) | Reference for the RBAC redesign. Sovereign currently spreads this across three ctl.* tables. |
| tenant | 2 tables (Tenants, TenantSettings) | Reference for multi-tenant isolation. Sovereign has one table at zero rows. |
| policy | 2 tables (Policies, PolicyRules) | Reference for the Policy Resolver schema in Section 4 of the manual. |

**Directive:** Before you design any new license, IAM, tenant, or policy table for Sovereign, spend half a day reading the matching schema in FuturisticREPO. Adopt the patterns that fit. The architectural thinking is already done — your job is to integrate it cleanly into Sovereign, not to redo it.

### 3.3 The hygiene gaps to address before any feature work

1. SovereignRepository has never been backed up. Set up a nightly full backup with weekly verification before you do anything else. The product preaches recoverability; the product database must practice it.
2. The pilot fleet table was wiped by yesterday's migration with no audit trail. Implement the rule that no migration runs against the repository database without writing an entry to the audit chain naming the migration, the actor, the affected tables, and the row counts before and after.
3. Three default user accounts with publicly-known bcrypt hashes (admin, operator, auditor at sovereign.local) exist in ctl.ConsoleUsers. Disable them today. Replace seeding with a first-run setup wizard that prompts for credentials and never writes them to source code.
4. No direct DML against the repository database. Every change goes through migrations or API endpoints. Document this rule, enforce it in code review, train the team.

## 4. Where to put focus, in priority order

The Engineering Handoff Manual lays out 12 sections of work. This section tells you which to start, when, and why. Treat this as the operational sequence; treat the manual as the reference for how each piece is built.

### 4.1 Focus Zone 1 — Hygiene and gates (Week 1)

You cannot build the rest of the product on a foundation that quietly loses data. Close this zone before anything else.

5. Set up nightly full backup of SovereignRepository with weekly verified restore to a side database.
6. Find the two unauthenticated write endpoints. Add requireAuth and requireRole. Verify with curl. Ship today.
7. Add requireAuth to every read endpoint in app.js. The current 18.8% must become 100% by end of week. Do not add new endpoints during this week. Just close gates.
8. Add a CI check that fails the build if any app.get / app.post / app.put / app.delete / app.patch declaration does not include either requireAuth or ingestAuth.
9. Disable the three seeded default accounts in ctl.ConsoleUsers. Build a first-run setup wizard. Remove the bcrypt hashes from db.js entirely.
10. Add audit chain logging to the migration runner. Every migration writes a hash-chained entry naming itself, the actor, and the tables affected before and after.

**Definition of done:** External penetration of the API surface returns 401 for every endpoint not explicitly public. Migrations cannot run silently. Default credentials are out of source and out of the database. Backups are happening nightly. Until these are true, no other work proceeds.

### 4.2 Focus Zone 2 — License manifest and feature gates (Weeks 2-4)

Without this, you cannot ship to multiple industries. This is the work that turns the product from a SQL Server tool into a license-driven enterprise platform.

11. Read FuturisticREPO.licensing schema before you design tables. Adopt the Products → ProductSkus → Licenses → Entitlements pattern.
12. Design the License Manifest format. Signed JSON, Ed25519 via @noble/ed25519. Schema in Section 3.1 of the manual.
13. Implement the manifest loader. Verifies signature against root key embedded at build time. Loads on startup and on file change.
14. Build the Feature Gate Registry as a single in-code map. Every gate-able capability in the product has a code. Every featureGate call references a code in the registry. CI fails if a featureGate call references an unknown code.
15. Refactor the existing featureGate middleware to read from the manifest, not config flags.
16. Apply featureGate to all 405 routes. Current 18.8% must reach 100% by end of zone.
17. Build the Settings → License UI page showing current manifest contents, expiration, enabled features, hardware binding status.
18. Build the offline license install flow. Customer drops a .license file in a designated directory; product picks it up at next start.
19. Issue Community, Professional, and Enterprise test manifests. Verify product behaves correctly under each.

**Definition of done:** Three different test manifests produce three observably different products from the same binary. A community user sees three monitored instances and no compliance packs. An enterprise user sees the full feature set. No code path branches on edition.

### 4.3 Focus Zone 3 — Policy & threshold framework (Weeks 3-5, parallel)

Run this in parallel with Focus Zone 2. They share the same underlying principle (data-driven configuration) and the same engineers can iterate on both.

20. Read FuturisticREPO.policy and FuturisticREPO.config schemas. Note: config.ComplianceThresholds in FuturisticREPO already has 29 rows of seeded threshold data. Mine that data; it is starting material.
21. Build the Policy Threshold Catalog table (schema in Appendix B of the manual). Seed with 80-120 policies across Capacity, Performance, Availability, Security, Compliance, Patching, Change Governance, FinOps.
22. Each policy carries industry defaults for Commercial, Financial, Healthcare, Government, Defense. Each carries floor, ceiling, citation source.
23. Build the Customer Policy table for tenant-scoped overrides. Build the Policy Validator that enforces floor and ceiling at write time.
24. Build the Policy Resolver service. This is the single in-process path code uses to read a threshold. Precedence: per-asset exception, per-tier override, tenant override, industry baseline default.
25. Refactor the existing route files to call the Policy Resolver instead of using hardcoded numbers. Discovery flagged 100 hardcoded threshold patterns to migrate.
26. Build the Policy Library UI page (browse the catalog) and the Policy Editor (admin override with justification and approver).
27. CI check: no literal numeric threshold in any route or service file. Build fails if found.

**Definition of done:** Every threshold the product enforces is editable through the admin UI under role-gated workflow. No literal number in route code. An auditor can ask "where did this threshold come from?" and the product can answer with a regulation citation.

### 4.4 Focus Zone 4 — Data collection pipeline (Weeks 1-6, urgent)

The biggest functional gap. Eleven fact tables are empty. The product cannot prove its value without data. Start this in Week 1 with whoever is not on Focus Zone 1, and run it in parallel through Week 6.

28. Build the PowerShell collector for SQL Server. Uses gMSA or domain account with VIEW SERVER STATE and CONNECT SQL only. Never sa.
29. Harden the existing /api/ingest/* endpoints. Move from ingest key auth to mTLS with per-agent client certificates issued at install time.
30. Build the validation layer. Reject payloads that violate schema or report values outside reasonable bounds (negative free space, future timestamps, impossible CPU values).
31. Build the CollectionState tracker. Every domain (telemetry, backup, hadr, patch, jobs, volumes, security) has a per-server state row. Last attempt, last success, failure reason.
32. Wire CollectionState into every API endpoint that returns fact data. The truthfulness gate depends on this. Every KPI declares its dataAsOf and collectionState.
33. Re-register the eight pilot servers through /api/fleet/register (not direct SQL). This tests the auth-gated registration path and produces real audit chain entries.
34. Start one collector against one server. Get one row into perf.Snapshots. Prove end-to-end. Then scale to the other ten fact tables and remaining seven servers.
35. Add the Python collector framework for PostgreSQL, MySQL, MariaDB. Uses pg_monitor or equivalent. Never superuser.

**Definition of done:** At least eight servers register and report telemetry, jobs, backups, hadr, patch, inventory, and volumes. Every dashboard either shows real data with a fresh timestamp or explicitly says "not collected." No zero rendered as truth anywhere.

### 4.5 Focus Zone 5 — Power BI executive dashboards (Weeks 6-10)

Boards and executives do not log into DBA tools. They look at Power BI. This is one of three things that turn Sovereign from a tool into a platform. It is also the deliverable that makes a board meeting effortless for the customers who pay the most.

36. Harden the OData v4 endpoints already scaffolded in routes/odata.js. Paginate, schema-stable, $metadata document complete.
37. Build the Power BI custom connector. Handle authentication, row-level security pass-through.
38. Build the seven dashboards listed in Section 8.2 of the manual: Board Risk, CIO Operations, CISO Security, CFO Cost, Compliance Officer, DBA Manager, DR Officer.
39. Submit the template app to Microsoft AppSource. 60-90 days from submission to listing. Start early.
40. Build the native React equivalents for customers without Power BI. One metric definition, two rendering paths.

### 4.6 Focus Zone 6 — Predictive engine v1 (Weeks 8-12)

The four predictions customers actually want: capacity exhaustion, performance degradation, backup failure risk, license waste. All run locally via ONNX Runtime. No network calls. Every prediction returns the value, confidence score, input features, model version.

41. Build the time-series feature store from perf.Snapshots data. Materialized view refreshing every 15 minutes. Rolling windows, seasonality decomposition, lag features.
42. Train a baseline model per prediction type using whatever data is in production. Ship as .onnx files.
43. Build the in-process inference service. No network calls. Returns value, confidence, features, version.
44. Build the backtesting dashboard. Show prediction accuracy against last 90 days of actual outcomes. Customers must see whether to trust the predictions.
45. Every prediction in UI carries a confidence score and the data window. Never present a prediction as a fact.

### 4.7 Focus Zone 7 — Simulator (Weeks 4-12, parallel)

This is the differentiator nobody else has and the second business model on top of the platform. Specification is in Section 11 of the manual. Build in parallel with the other zones; the work parallelizes well because the data backend already exists.

46. Build the Scenario Engine. YAML or JSON scenario files. Versioned and signed.
47. Build the Synthetic Telemetry Generator. Real metrics responding to learner actions. The hardest engineering piece.
48. Author the first five scenarios in collaboration with a working DBA. Ship these in Community edition.
49. Build the Assessment and Certification subsystem. Every learner action captured into the audit chain. Certificates are signed Sovereign artifacts with verifiable hashes.
50. Launch with 20 scenarios spanning DBA, SysAdmin, Security Analyst, and Compliance Officer personas, three difficulty tiers each. Full list in Section 11.4 of the manual.
51. Build the public certificate verifier endpoint. Employers paste a hash and confirm the learner completed the scenario.

## 5. Working agreements

These are the team rules that keep the four product commitments in place when nobody is watching. Treat them as non-negotiable.

### 5.1 Code review rules

- Every new route in app.js shows its requireAuth (or ingestAuth), requireRole, and featureGate in the pull request description. Reviewer rejects if any are missing.
- Every new metric in the product declares its dataAsOf source. No metric ships without a stated freshness contract.
- Every new threshold reads from the Policy Resolver. No literal number in route or service code.
- Every state change writes to the audit chain. No bypass for "small changes" or "internal operations."
- No commit to the main branch contains console.log, console.warn, console.error in production code paths. Use structured logging. Discovery found 3,687 console.* calls; clean these up as you touch each file.

### 5.2 Daily standup format

Once a day, fifteen minutes, three questions per person:

52. What gate did I close yesterday? (Control, Truthfulness, Identity, Audit, Repository, Licensing, Configuration, Structure)
53. What gate am I closing today?
54. What is blocking me?

Anything outside the gates is a distraction this month. Track it on a Later list; review at end of week.

### 5.3 What to escalate to product ownership

- Any customer ask that would require a hardcoded branch on industry, tenant, or edition. The answer is always a new policy or a new feature code, never a code branch.
- Any pull request that adds telemetry exfiltration, even for innocuous reasons (crash reporting, usage analytics, version-check pings). Sovereignty is a hard constraint.
- Any schema migration that would break the additive-only commitment to the existing ctl.Servers UNIQUEIDENTIFIER scheme.
- Any request to ship with the truthfulness gate disabled "just for the demo." There are no demo exceptions.
- Any compliance certification opportunity (FedRAMP, SOC 2 Type II, CJIS audit, StateRAMP). Product ownership manages the certification roadmap as a separate workstream.

### 5.4 What to celebrate

Database tools that ship across regulated industries are rare. Most fail because they cut corners on auditability or because they try to be everything to everyone and end up serving no one. The architectural discipline you bring this month is what separates a tool from a platform. Celebrate the gate closures, not the feature counts. A week where you closed twelve unauthenticated endpoints is more valuable than a week where you shipped six new dashboards.

## 6. The first ten working days

A concrete schedule. Adjust to your team size, but keep the order.

| Day | Workstream | Outcome |
|-----|------------|---------|
| 1 | Onboarding, read manual + this doc, walk the codebase | Team has shared mental model |
| 1 | Set up nightly backup of SovereignRepository | Recoverability baseline established |
| 2 | Find and gate the two unauthenticated write endpoints | Highest-risk surface closed |
| 2 | Disable seeded default user accounts; plan setup wizard | No default-credential exposure |
| 3 | Start auth gate closure on the 99 unauthenticated reads | First 20 routes gated |
| 3 | Read FuturisticREPO licensing schema | License Manifest design starts informed |
| 4-5 | Continue auth closure; design License Manifest format | 50% of reads gated; manifest spec drafted |
| 4-5 | Build PowerShell collector skeleton | One agent installable, even if not collecting yet |
| 6 | CI check added: every route shows requireAuth or ingestAuth | Drift prevented |
| 6 | Re-register one pilot server through /api/fleet/register | Auth + registration path proven |
| 7 | 100% of reads gated. Manifest loader + verifier built | Control gate green for read endpoints |
| 7 | First row lands in perf.Snapshots from the live collector | Truthfulness gate has data to prove |
| 8-9 | Feature Gate Registry built; first 100 routes wired to manifest | License-driven gating active |
| 8-9 | Audit chain wired into migrations runner | No more silent schema changes |
| 10 | Demo to product ownership: three test manifests, one binary | Sovereign is observably license-driven |
| 10 | Retrospective. Adjust focus zones for weeks 3-4 | Plan refined |

## 7. What success looks like at twelve weeks

Twelve weeks from start, you should be able to demonstrate every one of these. If you cannot demonstrate them, the product is not yet shippable to a paying enterprise customer regardless of how many features have been added.

55. Every API route is authenticated, role-gated, feature-gated, and tenant-scoped. A penetration test of the public surface returns 401 for every non-public endpoint. CI verifies this on every commit.
56. Every threshold and framework in the product is editable through admin UI under audit. No numeric literal threshold in any route or service file.
57. License manifests for Community, Professional, Enterprise, Government, and Defense editions are issued, signed, and tested. Product behaves correctly under each.
58. The data pipeline collects from at least three engine types (SQL Server, PostgreSQL, MySQL). At least eight servers report current telemetry, jobs, backups, HADR, patch, inventory, and capacity data.
59. Every dashboard either shows real data with a freshness timestamp or explicitly labels uncollected data. The truthfulness gate is observably enforced.
60. The Power BI template app is submitted to Microsoft AppSource. At least three of the seven dashboards are live and usable against the product's OData endpoints.
61. The predictive engine returns calibrated, confidence-scored predictions for capacity and patch lag. Backtesting accuracy is at least 75 percent on a 30-day backtest.
62. The Simulator has at least five scenarios live for Community users and twenty for paid users. Certificates are signed and verifiable through a public endpoint.
63. Air-gap operation passes an automated test asserting no outbound network calls during a 24-hour run.
64. A third party can verify a signed evidence package using only the package, the public key, and a small open-source verification tool. No Sovereign software required.
65. The audit chain has zero breaks. Merkle proofs reconstruct end-to-end.
66. SovereignRepository has a tested restore from last night's backup. Hygiene is operational, not aspirational.

## Closing direction

You have inherited a product with conviction. The architectural commitments to data sovereignty, truthfulness, audit defensibility, and air-gapped operation are not marketing language; they are the product's reason to exist. Most database tools cannot make these claims because they were not built with them as constraints. Sovereign was. Your job is to finish that work without compromise, across every industry the licensing tiers cover, with discipline and without shortcuts.

Build what is unique. Integrate everything else. Make every number defensible. Make every action auditable. Make every gate license-driven. Make every threshold industry-aware. Make every artifact verifiable by a third party. When in doubt, escalate. The cost of a five-minute conversation is much smaller than the cost of an architectural decision that has to be reversed in month six.

Welcome to the team. Build it the way it deserves.

— Issued by Rhoylle Innovation Empire LLC  
DBAOps™ Serial No. 99717776 · Team Instructions v1.0
