NuX HoldingsNuX Holdings
N
NuX Holdings™
Security & Governance
Security & Governance Center

Trust is a surface, not a slide.

NuX Holdings™ is built as enterprise infrastructure — not a dashboard. This page is the single artifact your security, risk, and legal reviewers can read end-to-end before procurement.

Pillar

Multi-Tenant Isolation

Every client organization is provisioned as a ring-fenced workspace. No cross-tenant joins, no cross-tenant reads, no shared scoring state.

  • · Row-Level Security enforced at the database boundary on every governed table
  • · Per-tenant workspaces with isolated benchmarks, doctrine, and scoring config
  • · CSV uploads land in tenant-scoped storage paths; service-role access is server-only
  • · Privileged server functions verify caller identity AND role before touching admin APIs
Evidence
Tenant scope is a structural property of the schema, not a runtime filter.
Pillar

Immutable Audit Ledger

Every privileged action — mode changes, doctrine edits, demo seeding, document writes, AI Oversight overrides — is recorded with actor, target, timestamp, and metadata.

  • · Append-only audit_log table with actor, action, target, and structured metadata
  • · Visible to founders and super-admins under /audit (founder-gated)
  • · Retained for the life of the engagement; exportable on request
  • · Mode transitions (Field / Boardroom / Audit) are themselves audit events
Evidence
If it changed governance or shipped to an executive surface, it is in the ledger.
Pillar

Human Approval at the Boundary of Judgment

AI Oversight is a gate, not a co-pilot. Any score, doctrine action, or executive narrative that crosses the judgment threshold is human-reviewed before it leaves the platform.

  • · NuX v0.1 scores are tagged ● Measured · Human-reviewed only after audit
  • · Directive 6 composites that escalate exposure require human sign-off before Watchtower release
  • · AI Oversight chat is logged; overrides are audit events with reviewer attribution
  • · No model output is auto-published into Executive Command without a human in the loop
Evidence
Doctrine VI: judgment belongs to humans; the platform shows its work.
Pillar

Data Retention & Minimization

NuX Holdings ingests the interaction signal it needs to score — not the raw enterprise corpus. Retention is bounded by engagement scope and revocable by the tenant.

  • · CSV ingestion is field-mapped; only fields used by NuX v0.1 / Directive 6 are persisted
  • · Personally identifying fields are governed under the client DPA, not stored speculatively
  • · Tenant-initiated export and deletion paths are part of the Annual Platform Agreement
  • · Backups are tenant-scoped and inherit RLS on restore
Evidence
Minimization is contractually defended in the DPA and structurally defended by the schema.
Pillar

Doctrine I — No Automated Adverse Decisions

NuX Holdings will not, by design, automate a decision that materially harms a person. Scoring informs judgment; it does not replace it.

  • · Adverse-action paths require a named human decisionmaker, recorded in the audit ledger
  • · Doctrine I is enforced at the doctrine layer and surfaced in every Executive Briefing
  • · Model outputs flagged as adverse are blocked from auto-publish surfaces
  • · Reviewers see the evidence chain — not just the score — before signing
Evidence
Doctrine I is non-negotiable. It is the reason NuX Holdings exists.
Pillar

Identity, Roles & Access

Every governed user is a named identity with a scoped role. Roles are stored separately from profiles and checked via a security-definer function — never trusted from the client.

  • · Roles in user_roles (viewer / admin / founder / super_admin), checked via has_role()
  • · Founder and super-admin surfaces are gated server-side, not just hidden in the UI
  • · Auth flows use the platform's managed provider; no password handling in app code
  • · Session refresh and sign-out are honored across orientation, viewport, and reload
Evidence
Privilege is a function of role + tenant scope, evaluated on every request.
Reviewer Checklist

What your security review will find

  • ✓ Tenant isolation enforced at the database, not the application
  • ✓ Privileged actions logged with actor, target, and metadata
  • ✓ Role checks performed server-side via security-definer functions
  • ✓ No client-trusted admin state; no role storage on profiles
  • ✓ Human approval on every adverse or executive-surfaced output
  • ✓ Confidence framework visible on every score (Measured / Illustrative)
  • ✓ Data minimization defended contractually (DPA) and structurally (schema)
  • ✓ Doctrine I — no automated adverse decisions, enforced by design
Next

How the scoring works.

Measurement Standards & Provenance →