Skip to main content

Consulting

The experiences turn one governed workspace toward the person using it. Consulting turns the same machinery outward, at a customer's estate the platform does not yet run. It is the platform's catalog, cognition, and posture engines, pointed at someone else's data platforms, clouds, and on-premises systems, and delivered as a signed, re-runnable artifact rather than a slide deck.

Commercially this is the assess-then-land motion: an assessment that ends with runnable infrastructure-as-code the customer can apply is a paid, low-risk first engagement that does not require deploying the platform into production first, revenue before deployment. This page describes what that capability really is, lens by lens, and is deliberately strict about what is shipped versus what is roadmap.

Read this before quoting anything on this page

This is the section most likely to over-sell. Two rules hold throughout:

  • Only the data-governance lens is the mature, sell-it lens. The other lenses are real engines for posture, misconfiguration, entitlement, migration, and virtualization scoring, but with control libraries, active discovery, and some connectors incomplete. The platform can credibly deliver a threat, posture, and exposure assessment and operate a small-scale SIEM; it can model attacks but cannot run a live penetration test.
  • A lens's runnable flag is a mechanical fact, not a maturity claim. It means only "the assessment runner can dispatch this lens." The most mature lens (Data) is runnable = false because it runs catalog-side, not through the runner. Never read runnable = true as "production-grade."

The assessment lenses, and what each one covers​

The consulting capability is organized as lenses over one workbench: the same workspace, the same assistant, applied through a chosen assessment lens. The narrative leads with four headline lenses (Data, Security, Cloud, Virtualization); the live lens registry exposes eight lens ids, each with a plain, public id and label. This is the authoritative set, read directly from the backend Discovery & Mapping lens registry and projected to Terraform by the system9_consulting_lenses data source.

Lens idLabelAssessment engines (source_kinds)Runner-runnableMaturity
dataData(none: catalog-side governance)NoShipped, mature. Governance scorecard, compliance gap grid (GDPR/HIPAA/SOX/CCPA), remediation roadmap, recommendations, signed HTML/PDF deliverable. Runs through the catalog data tools, not the assessment runner. This is the lens to sell.
securitySecuritycspm, ciemYesReal engines, partly built. Cloud misconfiguration + control mapping (CSPM) and entitlement/privilege-escalation analysis (CIEM) are real, pure engines. Control libraries are partial; SIEM event storage is an in-memory prototype; active discovery is simulated. Describe as roadmap.
cloudCloudcspm, migration, finopsYesReal engines, partly built. Misconfiguration, 6-R migration planning with total-cost modelling and wave sequencing, and FinOps rightsizing / commitment / well-architected review: all real. Some connectors incomplete. Roadmap.
virtualizationVirtualizationvmwareYesReal engine, partly built. vSphere estate inventory, sprawl analysis, and migration-readiness (13 hardening rules). Reaches on-prem virtualization managers via the edge. Roadmap.
data_securityData securitydata_securityYesReal data-platform security-posture engine. Newer; name it as the specific slice it is, not "security" in general.
storageStoragestorageYesReal storage-hygiene engine.
storage_exposureStorage exposurestorage_exposureYesReal permission-exposure engine: the "who can reach this" slice over storage.
ai_governanceAI governanceai_governanceYesReal AI-governance engine mapping to NIST AI RMF / ISO 42001.
What is real, what is a prototype, what is a stub: verified in code
  • Real, deterministic: the data-governance scorecard and recommendations engine; the CSPM misconfiguration + compliance-mapping engine; the CIEM privilege/escalation engine; the FinOps rightsizing/commitment/well-architected engines; the 6-R migration planner (with TCO + wave sequencing); the vSphere readiness/sprawl/inventory engine; the IaC render + signed-deliverable path; the rules-of-engagement model.
  • Coverage-dependent by design: the compliance control libraries return NOT_EVALUATED (never a false PASS) for any control with no registered check, so coverage depends on which checks are wired, and many controls read as not-yet-evaluated rather than passing.
  • Prototype: SIEM event storage is in-memory (a Phase-1 ring buffer that requires an explicit non-persistence acknowledgement before use).
  • Stub / simulation: active discovery generates simulated hosts (no real packet scan); exploitation and lateral movement are simulation only (modelled from CVSS). The platform models attacks; it does not run a live pentest.
  • Not on the assessment path: the cognition subsystems (entity resolution, sensitivity inference) are real and toggleable but gated off by default (AI_OFF), and are not part of the assessment run itself. The cryptographic posture engine (certificate/key/trust-chain scoring and crypto blast-radius) is real but is the cell's own PKI posture, not the consulting security lens.

How an assessment runs​

An assessment is not a live-fire scan behind a button. It is a governed job. Enqueue is a cell-side BFF call that passes through the authorization gates before a single row is written, and a worker drains it onto pure, I/O-free engines.

Figure C1: an assessment run. The authorization gates (red) all pass before a run row exists: the engagement must be bound to the workspace, the target must be in the signed rules-of-engagement scope (fail-closed on an unlisted target), a live scan is gated by the deployment profile, and the net-potential-gain gate plus N-of-M approval must clear, with a tamper-evident audit stamp either way. Only then does a pending run enter the queue. A worker drains it onto pure engines (grey) that do no I/O, and the green stages materialize findings, a scorecard, a deliverable, and finally a signed, hash-chained IaC deliverable. A refusal (amber) is recorded, not silently dropped.

Table equivalent

StageWhere it runsWhat it does
EnqueueCell BFF (consulting_router.py)Accepts the assess request for an engagement + source kind
Scope + lens gateCellConfirms the workspace owns the engagement and the lens permits the source kind
Rules of engagementCellChecks the target against the signed scope; fail-closed on anything unlisted
Sovereign gateCellGates live scans by deployment profile (sovereign/air-gapped restrictions)
NPG + N-of-M + auditCellNet-potential-gain gate and multi-party approval; stamps the tamper-evident audit chain
Drain + resolveCell workerPulls the pending run and resolves inventory for the source
Runner dispatchCell (assessment_runner.py)Dispatches on source_kind to the matching pure engine
EnginesCell (core/security/*)Deterministic, I/O-free finding builders
Findings → scorecard → deliverableCellMaterializes findings, scores them, composes Markdown + HTML
Signed IaC deliverableCell (estate IaC service)Content-hashes, approver-signs, and hash-chains the runnable artifact

What an assessment produces​

The engagement is the object; these are its outputs:

  • Findings: severity, subject, remediation, and control mappings, with the engine's raw properties attached and a lifecycle state per finding.
  • A governance scorecard: an overall health score, per-dimension scores (data quality, sensitivity, coverage, compliance), a compliance-control gap grid, and a prioritized remediation roadmap.
  • A client deliverable: composed Markdown and HTML.
  • A migration plan: 6-R disposition with total-cost modelling and wave sequencing (surfaced in finding properties).
  • Infrastructure-as-code export. Terraform: CloudFormation, Bicep, or ARM, rendered from the inventory (as_is) or from a target-architecture diagram (to_be), with no cloud credentials involved.
  • A signed IaC deliverable: the export, content-hashed, approver-signed, and written into a tamper-evident hash chain.
  • A signed scope manifest: the rules-of-engagement, signed and verifiable.
  • Recurring schedules: the assessment re-runs and tracks drift; it is living, not a dead deck.

Frontend: the consulting console​

The consulting console is the engagement surface, reached through the single consulting tab in the workspace console (labeled "Data, cloud, and security assessment engagements"). Because the Consulting experience foregrounds exactly that tab plus the always-on governance tabs, a consultant sees a focused engagement workbench, not the full 56-tab platform.

  • The tab is gated by a backend Capability Control capability for governance assessment; if that capability is not enabled for the workspace, the Consulting experience is not even offered in the switcher (per "gate, don't omit", the capability is the real boundary, the tab is the view).
  • From it, a consultant runs engagements, reviews findings and the scorecard, signs the scope, composes and exports the deliverable, and requests the IaC artifact.
  • An assistant/copilot plans an assessment over a catalog of assessment tools, a grounded planner that renders an auditable plan-before-execute manifest.
The copilot is plan-first

The assessment copilot plans today; end-to-end execution of a planned manifest is owed work, not a shipped wrapper. The plan-before-execute manifest renders for review (that is real and is the point of the design), but treating the copilot as an autonomous executor overclaims the current state.

Backend: the assessment engine and the lens registry​

The engine is a clean separation of policy, dispatch, and pure computation:

  • The lens registry (assessment/lens_registry.py) is the authoritative, in-code set of lenses and their source_kinds, with runnable = bool(source_kinds).
  • The BFF (consulting_router.py) owns all the authorization (scope, ROE, sovereign gate, NPG + N-of-M, audit) and the read/enqueue surface.
  • The runner (assessment_runner.py) is pure dispatch + map + write: it dispatches on source_kind to a row-builder that calls a pure engine and writes findings through an injected DAO. The engines under core/security/* (CSPM, CIEM, FinOps, migration, vSphere, data-security, storage, storage-exposure, AI-governance) do no I/O. They are deterministic functions over resolved inventory.
  • The deliverable + IaC path composes Markdown/HTML and seals a content-hashed, approver-signed, hash-chained IaC deliverable through the estate IaC service.

The Terraform data source is real. system9_consulting_lenses (in the native system9 Terraform provider) is a read-only data source: given a workspace_id, it performs a live GET against the consulting-lenses endpoint (requiring the consulting read capability) and returns each lens as { lens_id, label, description, source_kinds, runnable }. It is a thin projection of the registry above, no status, reach, or deliverable fields are invented on the wire; the schema exposes exactly what the registry knows.

Core and edge: where each part runs​

The assessment engine is trunk-only: the lens registry, the runner, the engines, the scorecard, and the signed-deliverable path all run on a cell (core). Cells are the web-tier reach, they connect to cloud data platforms and cloud control planes (AWS including GovCloud/ISO, Azure including Government, GCP including Assured Workloads) and run the assessors and the aggregation.

The edge is the data-gathering leaf, not the engine. Where data lives on-premises, on network-attached storage, or behind an air gap, where a cell cannot sit, the Edge Agent scans it in place, runs first-pass perception (extraction, classification), builds a deterministic inventory, and ships findings, not raw bytes back to a cell, over the live fabric or as signed offline transfer bundles when there is no link at all. Each edge partial is signed and provenance-bearing, and the net-potential-gain gate is held at the leaf when a partial is unjudgeable, an edge that cannot score a result refuses rather than guessing.

Figure C2: consulting reach. The cell runs the assessment engine and reaches cloud platforms directly; the Edge Agent is a data-catalog leaf that scans data that cannot move and ships signed findings to a cell, over the fabric or as an offline bundle. The assessment lenses, scorecard, and signed deliverable do not run on the edge; the edge feeds them.

Table equivalent

ConcernCore (cell)Edge (Edge Agent)
Lens registry, runner, engines, scorecardYesNo: trunk-only
Signed deliverable + IaC exportYesNo
Reach cloud data platforms / control planesYes (direct)No
Scan on-prem / NAS / air-gapped data in placeNo (a cell cannot sit there)Yes: this is the edge's job
First-pass perception + deterministic inventoryOptionallyYes, at capture
Ship findings not raw bytes; signed partials; offline bundlesYes
NPG gate held on an unjudgeable resultYes, at the leaf
Edge consulting is leaf-scanning, not lens execution

The Edge Agent repository contains a Discovery & Mapping data-catalog leaf runtime (scan → perception → inventory → replicate to trunk, plus sneakernet bundles). That is a distinct capability from the consulting assessment. The lens registry, the assessment runner, the scorecard and the signed deliverable run on a cell, not on the Edge Agent. Making crews, and so scanner steps, portable to Edge Agents is on the roadmap.

The two infrastructure-as-code stories: do not blur them​

Consulting rides on IaC export, and it must not be confused with managing the platform's own estate:

  • Infrastructure-as-code export (the consulting deliverable). The assessment renders a customer's scanned estate as Terraform/CloudFormation/Bicep/ARM from the inventory, with no cloud credentials involved. This is the artifact the engagement hands over.
  • Estate-as-code (managing System9 itself). A separate product: declaratively managing System9's own service groups, workspaces, clean rooms, and databases through the native Terraform provider. That is covered under Software engineering · Infrastructure as code.

Say it as: "We manage our own estate declaratively, and we can hand you yours as code."

Consultant tooling across data, security, and app-dev​

One workbench, applied through the lenses, spans the consultant's three domains:

  • Data: governance, quality, lineage, and personal-data assessment; semantic- model translation and health; SQL dialect and stored-procedure conversion; diagram generation; and migration planning. This is the mature, sell-it lens.
  • Security: posture, maturity, threat model, exposure, and detection coverage; entitlement and privilege-escalation analysis; misconfiguration; and a small-scale SIEM. Real engines, roadmap coverage, and it models attacks rather than running live ones.
  • App-dev / cloud: code intelligence over a customer source tree (content- addressed artifacts scoped to an engagement, AST extraction, modernization-effort scoring); cloud posture, FinOps, and 6-R migration; and the IaC export that ends the engagement with something the customer can apply.

The defensibility of the motion is not any one scanner, open-source scanners are a commodity. It is the layer around them: fleet reach across air-gapped, on-prem, and multi-cloud simultaneously; sovereign cognition that can enter export-controlled estates; cross-domain correlation (one finding that is a data and security and virtualization and cloud fact at once); signed, tamper-evident deliverables; and governed, authorized, re-runnable execution.