Sentra Nexus

Sentra Nexus is a frontend-first operational intelligence control plane for regulated, AI-assisted decision workflows, designed to demonstrate modular React architecture, policy-aware product modelling, explainable AI support, auditability, and production-minded UX.

Overview

I built Sentra Nexus to show how I approach serious product surfaces where frontend architecture, domain modelling, operational UX, and AI governance all matter at the same time.

The project is intentionally framed as an internal control plane rather than a landing-page-heavy demo. It focuses on constrained decisions, evidence visibility, workflow state, incident handling, auditability, system health, and human-in-the-loop AI assistance. The result is a product surface that is much closer to a real operational platform than a static showcase.

This project also complements backend-heavy workflow systems by making the frontend layer substantially more visible: route composition, feature boundaries, domain-led behaviour, state handling, reliability surfaces, and explainable recommendation UX are all explicit and inspectable.

What this project demonstrates

Sentra Nexus demonstrates how I design and implement a production-minded frontend system with clear boundaries between presentation, domain logic, services, state, and AI support.

It highlights:

• modular React and TypeScript architecture
• feature-first organisation with reusable UI primitives
• typed domain entities, rules, validators, and policies
• explicit workflow constraints and approval guardrails
• operational control-plane UX instead of generic dashboard decoration
• evidence-aware AI recommendation surfaces with visible limitations
• audit and machine-origin visibility
• degraded-mode and latency-aware product thinking
• layered automated testing across unit, integration, contract, and end-to-end scopes
• disciplined Git history and quality gates

Product scope

Public product layer

The public-facing routes establish the platform narrative and design language:

• landing page
• about
• platform
• solutions
• trust
• security
• architecture
• case study
• contact

These pages are not filler. They are designed to communicate the product’s trust posture, architectural intent, workflow seriousness, and operational context.

Operational control plane

The demo routes model the internal product surface:

• Command Center for backlog health, approval ageing, bottlenecks, timelines, and blocked AI recommendations
• Intake and Triage for completeness checks, routing priority, assignment controls, and triage scoring
• Workflow Operations for table and Kanban-style tracking, saved views, due-date heat, blocked-state reasons, and retry framing
• Policy Decisions for constrained action handling, disallowed states, reason capture, and decision history
• Incidents and Exceptions for severity, blast radius, remediation, and linked workflows
• Evidence Explorer for provenance, source status, evidence gaps, and recommendation relationships
• Audit Timeline for actor visibility, reason codes, linked entities, and human-versus-machine origin tracking
• Analytics Lab for cycle time, latency, exception rate, SLA attainment, bottlenecks, throughput, and workload concentration
• System Health for degraded-mode, latency, retry, and service-state visibility
• AI Decision-Assist Workspace for recommendation rationale, evidence trace, confidence band, alternatives, blocked states, feedback controls, and override notes
• Evaluation Center for recommendation quality, reviewer agreement, false positives, false negatives, unsafe examples, and calibration framing

Architecture summary

The application is structured to keep product behaviour understandable as the surface grows.

Architectural approach

I used a feature-first frontend structure backed by a typed domain layer. That allows route modules and feature modules to remain easy to reason about while keeping business meaning reusable across the application.

The architecture separates:

• route composition and layout concerns
• reusable UI primitives
• feature modules
• domain entities, types, rules, policies, validators, and value objects
• typed service adapters
• seeded and scenario-based data
• app, workspace, and filter state
• AI recommendation logic
• telemetry helpers
• automated tests by scope

Why this matters

That separation makes the project useful as an engineering example, not just a visual example. Pages do not invent local business behaviour ad hoc. Shared workflow language, approval rules, evidence checks, and recommendation logic are modelled once and then reused consistently.

AI engineering decisions

The AI subsystem is intentionally governed.

Recommendations are generated from typed case and evidence inputs, then surfaced with:

• recommendation title
• suggested action
• rationale
• confidence value and confidence band
• evidence trace
• alternatives
• blocked-state reason
• approval requirement

The system does not present AI as autonomous. It presents AI as a constrained advisory layer under policy and reviewer control.

Human-in-the-loop guardrails

The product deliberately enforces several constraints:

• recommendations remain advisory
• high-risk and critical workflows still require human approval
• missing or stale evidence can block approval paths
• blocked-state reasons are shown explicitly
• reviewer feedback and override notes are first-class UI elements
• AI-origin actions are visible in the audit timeline
• evaluation is surfaced as part of the product rather than hidden as an offline-only concern

Reliability and operational UX

Sentra Nexus treats operational trust as part of the interface.

That includes:

• degraded-mode messaging
• latency visibility
• retry framing
• service-state visibility
• stale evidence handling
• blocked approval paths
• machine-origin audit traces

This is a deliberate design choice. Reliability should not be invisible until failure. In serious internal platforms, users need to understand system state, data freshness, and constraint boundaries while they are working.

Quality controls

I configured the project with production-minded quality gates:

• ESLint with strict TypeScript rules
• Prettier formatting
• Husky hooks
• lint-staged
• Commitlint
• Vitest with coverage
• Testing Library
• Playwright
• GitHub Actions CI
• MSW service worker setup for future network mocking expansion

Test strategy

The test suite is layered:

• unit tests cover rules, policies, value objects, and telemetry
• integration tests cover user-facing pages and critical interaction states
• contract tests validate seeded data shape and recommendation output
• end-to-end tests verify core public and demo route rendering

Tech stack

• React
• TypeScript
• Vite
• React Router
• TanStack Query
• Zustand
• React Hook Form
• Zod
• Tailwind CSS
• Radix UI
• Lucide React
• Vitest
• Testing Library
• Playwright
• MSW
• ESLint
• Prettier
• Husky
• Commitlint

Project structure

The repository is organised around features, domain boundaries, services, styles, tests, and documentation.

sentra-nexus/
├─ .github/
│  └─ workflows/
│     └─ ci.yml
├─ .husky/
│  ├─ commit-msg
│  └─ pre-commit
├─ docs/
│  ├─ adr/
│  ├─ architecture/
│  ├─ case-study/
│  ├─ decisions/
│  ├─ presentation/
│  ├─ qa/
│  └─ screenshots/
├─ public/
│  └─ mockServiceWorker.js
├─ src/
│  ├─ app/
│  │  ├─ layout/
│  │  │  └─ site-layout.tsx
│  │  ├─ providers/
│  │  │  └─ app-providers.tsx
│  │  └─ router/
│  │     └─ index.tsx
│  ├─ components/
│  │  ├─ feedback/
│  │  │  └─ status-banner.tsx
│  │  ├─ navigation/
│  │  │  └─ top-nav.tsx
│  │  └─ ui/
│  │     ├─ button.tsx
│  │     ├─ page-shell.tsx
│  │     ├─ panel.tsx
│  │     └─ section-heading.tsx
│  ├─ data/
│  │  ├─ scenarios/
│  │  │  └─ scenario-config.ts
│  │  └─ seed/
│  │     ├─ cases.ts
│  │     └─ evidence.ts
│  ├─ domain/
│  │  ├─ entities/
│  │  │  ├─ case.ts
│  │  │  ├─ evidence.ts
│  │  │  └─ recommendation.ts
│  │  ├─ events/
│  │  │  └─ audit-event.ts
│  │  ├─ policies/
│  │  │  └─ decision-policy.ts
│  │  ├─ rules/
│  │  │  ├─ approval-rules.ts
│  │  │  └─ evidence-rules.ts
│  │  ├─ types/
│  │  │  └─ workflow.ts
│  │  ├─ validators/
│  │  │  └─ case-validator.ts
│  │  └─ value-objects/
│  │     └─ confidence-band.ts
│  ├─ features/
│  │  ├─ about/
│  │  │  └─ about-page.tsx
│  │  ├─ ai-decision-assist/
│  │  │  └─ ai-decision-assist-page.tsx
│  │  ├─ analytics-lab/
│  │  │  └─ analytics-lab-page.tsx
│  │  ├─ architecture/
│  │  │  └─ architecture-page.tsx
│  │  ├─ audit-timeline/
│  │  │  └─ audit-timeline-page.tsx
│  │  ├─ case-study/
│  │  │  └─ case-study-page.tsx
│  │  ├─ command-center/
│  │  │  ├─ command-center-page.tsx
│  │  │  └─ use-command-center.ts
│  │  ├─ contact/
│  │  │  └─ contact-page.tsx
│  │  ├─ evaluation-center/
│  │  │  └─ evaluation-center-page.tsx
│  │  ├─ evidence-explorer/
│  │  │  └─ evidence-explorer-page.tsx
│  │  ├─ incidents/
│  │  │  └─ incidents-page.tsx
│  │  ├─ intake-triage/
│  │  │  └─ intake-triage-page.tsx
│  │  ├─ landing/
│  │  │  └─ landing-page.tsx
│  │  ├─ platform/
│  │  │  └─ platform-page.tsx
│  │  ├─ policy-decisions/
│  │  │  └─ policy-decisions-page.tsx
│  │  ├─ security/
│  │  │  └─ security-page.tsx
│  │  ├─ solutions/
│  │  │  └─ solutions-page.tsx
│  │  ├─ system-health/
│  │  │  └─ system-health-page.tsx
│  │  ├─ trust/
│  │  │  └─ trust-page.tsx
│  │  └─ workflow-ops/
│  │     └─ workflow-ops-page.tsx
│  ├─ lib/
│  │  ├─ constants/
│  │  │  └─ app.ts
│  │  └─ utils/
│  │     └─ cn.ts
│  ├─ services/
│  │  ├─ ai/
│  │  │  └─ recommendation-engine.ts
│  │  ├─ api/
│  │  │  └─ workflow-service.ts
│  │  └─ telemetry/
│  │     └─ logger.ts
│  ├─ state/
│  │  ├─ app/
│  │  │  └─ app-store.ts
│  │  ├─ filters/
│  │  │  └─ filter-store.ts
│  │  └─ workspace/
│  │     └─ workspace-store.ts
│  ├─ styles/
│  │  ├─ globals/
│  │  │  └─ index.css
│  │  └─ tokens/
│  │     └─ colors.css
│  ├─ tests/
│  │  ├─ contract/
│  │  │  ├─ case-schema.test.ts
│  │  │  └─ recommendation-engine.test.ts
│  │  ├─ e2e/
│  │  │  └─ public-and-demo.spec.ts
│  │  ├─ integration/
│  │  │  ├─ ai-decision-assist.test.tsx
│  │  │  ├─ contact-page.test.tsx
│  │  │  └─ system-health.test.tsx
│  │  ├─ unit/
│  │  │  ├─ approval-rules.test.ts
│  │  │  ├─ confidence-band.test.ts
│  │  │  ├─ decision-policy.test.ts
│  │  │  ├─ evidence-rules.test.ts
│  │  │  └─ logger.test.ts
│  │  └─ setup.ts
│  ├─ App.tsx
│  └─ main.tsx
├─ .env.example
├─ .gitignore
├─ commitlint.config.cjs
├─ eslint.config.js
├─ index.html
├─ package.json
├─ playwright.config.ts
├─ postcss.config.js
├─ README.md
├─ tailwind.config.js
├─ tsconfig.app.json
├─ tsconfig.json
├─ tsconfig.node.json
└─ vite.config.ts

Local setup

Prerequisites

• Node.js 20+
• npm
• PowerShell on Windows
• VS Code opened at the repository root

Repository root

D:\projects\sentra-nexus

Install dependencies

Set-Location "D:\projects\sentra-nexus"
npm install

Start the development server

npm run dev

Open the local URL shown by Vite.

To stop the dev server:

CTRL + C

If the process does not stop on the first interrupt, press:

CTRL + C

exactly one more time.

Build for production

npm run build

Preview the production build

npm run preview

Environment variables

Use .env.example as the baseline:

VITE_APP_NAME=Sentra Nexus
VITE_APP_ENV=development
VITE_ENABLE_MSW=true
VITE_SCENARIO=baseline
VITE_SIMULATE_DEGRADED_MODE=false
VITE_SIMULATE_HIGH_LATENCY=false

Commands

npm run dev
npm run lint
npm run test
npm run build
npm run test:e2e
npm run preview
npm run storybook
npm run build-storybook
npm run format
npm run format:check
npm run check

Screenshots

Public product layer

Operational control plane

Mobile

Engineering notes

Why the domain layer is explicit

I wanted workflow rules to be reusable and testable independently from the UI. That is why evidence sufficiency, approval requirements, policy decisions, confidence-band calculation, and schema validation all live in the domain layer instead of being embedded directly inside page components.

Why the AI surface is intentionally constrained

The recommendation engine is there to demonstrate governed decision support, not speculative autonomy. The project shows how to present AI assistance with rationale, evidence traceability, blocked states, approval requirements, alternatives, and evaluation visibility.

Why reliability is part of the interface

Degraded mode, retry visibility, stale-source handling, and mock service state are surfaced deliberately. In internal platforms, trust depends not only on whether the system works, but on whether users can understand what state the system is in while they work.

Documentation

The repository includes dedicated documentation for:

• architecture overview
• architecture decision records
• case study material
• QA evidence
• presentation walkthroughs
• trade-off records
• screenshots

Status

Current repository state includes:

• routed public product pages
• routed operational control-plane modules
• domain-led workflow modelling
• typed services and scenario configuration
• governed AI recommendation surface
• evaluation surface
• layered automated testing
• CI and local quality gates
• screenshot-ready UI structure

License

This project is licensed under the MIT License. See the LICENSE file for the full text.