Nexus Notebook
Organise trusted sources, manage access and continue evidence-grounded analysis.
Open Notebook →NEXUS ONE AI
Good to see you.
Work with enterprise AI, trusted knowledge and governed automation from one secure workspace.
START HERE
What would you like to do?
Ask Nexus AIWrite, analyse and explore with an approved enterprise model.Open workspace →
Search trusted knowledgeAsk source-grounded questions and inspect the supporting citations.Open Knowledge →
Compare documentsReview meaningful changes across governed business documents.Start comparison →
Build an applicationMove from a defined requirement to a controlled application release.Open App Studio →
YOUR WORKSPACE
Continue working
Runs and approvals
Review active jobs, scheduled work and decisions waiting for your attention.
View runs →Applications
Return to application projects, previews and controlled release activity.
View applications →PRIVATE ENTERPRISE AI
How can Nexus AI help?
Write, analyse, summarise and reason with an approved model inside your organisation’s governed environment.
APPROVED CHAT EXPERIENCE
Start or continue a conversation
Your Nexus identity is used automatically. Conversations and model access remain subject to your organisation’s policies.
Private by design
Prompts and responses stay within the governed Nexus environment.
Approved model path
The workspace uses the model alias and controls approved for your role.
Use Knowledge for evidence
For source-grounded answers and citations, start from a governed collection.
Open Knowledge →Workspace details and current limitations
Chat service: The approved conversational interface is provided by Open WebUI behind Nexus single sign-on.
Model: Keep nexus-default selected unless another approved option is explicitly available.
Evidence: General model answers are not source evidence. Use Nexus Notebook when citations or governed documents are required.
GOVERNED PROMPT ASSETS
Prompts
Prompt Library combines a governed shared catalog with private, versioned assets. Open Prompt Studio to compose and run durable expert-assisted requests.
Output
Ready
Choose an expert and action, enter your request, then run.
Results include durable job status, attempts and model evidence.Dataset Creation
GOVERNED DATA PREPARATION
Datasets
Create grounded examples, review every generated row, and publish an immutable version for evaluation or an approved training runtime.
Private by default
RECENT WORKDataset drafts and versions
Open a dataset to review generated examples| Name | Source | Model | Progress | Status | |
|---|---|---|---|---|---|
| No generation jobs yet. | |||||
Model Training
TRAINING DATA
Create datasetPublished datasets
Select an immutable dataset version created in Dataset Creation.
Loading published datasets…
GOVERNED FINE-TUNING
Checking runtimeLaunch LoRA training request
Every request records the dataset checksum, approved base model, configuration, and runtime evidence.
Checking signed runtime prerequisites…
AUDITABLE LIFECYCLE
Training request history
| Dataset | Base model | Method | Status | Requested |
|---|---|---|---|---|
| Loading training history… | ||||
SHARED QUALITY EVIDENCE
AI Evaluation + RAG Quality
AI Evaluation and Response Comparison share one evaluation engine. RAG Quality and Feedback Review share the same evidence and review records—four views without duplicate services.
REPEATABLE QUALITY PROGRAMS
Access controlledEvaluation Suites
Define reusable test cases, run approved models consistently, and preserve scored evidence for human review.
SUITE PROFILE
Suite details
TEST EVIDENCE
Test cases (0)
CONTROLLED EXECUTION
Start a new run
PERSISTED EVIDENCE
Past runs
HUMAN REVIEW
Feedback Review
Open an evaluation result, record disposition, rating, and comments, and preserve the review against its original evidence.
GOVERNED QUALITY EVIDENCE
Model CompareRAG Quality
Compare approved models with the same prompt and preserve judge evidence for review.Test retrieval against an accessible collection and inspect grounded quality evidence.
2Evaluation evidenceOpen a completed run to inspect scores, outputs and reviewer evidence.
Persisted and access controlledAgent Studio
GOVERNED AGENT DESIGN
Build a reusable AI agent
Define a focused role and operating constraints, test it with controlled inputs, then activate it inside an approved workflow.
Start from a proven patternTemplates create an editable draft. Nothing runs automatically.
WORKFLOW OPERATIONS
Durable executionRun and govern workflows
Start an approved definition, schedule it for later, and review decisions from the same operational queue.
GOVERNED COLLABORATION
Meeting Assistant + Chat Rooms
Meeting Assistant produces traceable summaries, decisions and actions from transcript evidence. Chat Rooms provide explicit membership and persistent human/AI conversation without duplicating Open WebUI.
MEETING-TO-ACTION
Private by defaultTurn conversations into accountable work
Import approved meeting evidence, review what Nexus extracts, then publish decisions and actions with traceable provenance.
GOVERNED TEAM COLLABORATION
Membership controlledWork together in persistent rooms
Invite explicit members, preserve the conversation, and request Nexus AI only when the room needs it.
MEETING HISTORYEvidence-backed artifacts
Select a roomMessages, members and evidence will appear here.
COMPATIBILITY WITHOUT DUPLICATION
Developer tools and adapters
Compatibility entries reuse the governed notebook, application, inference, vector and monitoring capabilities. Optional packages remain visibly degraded until installed through signed offline packs.
BUILDJupyter Notebook
Open notebookIsolated development workspace with the governed identity boundary.
INFEROpenAI-compatible API
checkingServer-side credentials · canonical model abstraction
STOREPostgreSQL + pgvector
Open knowledge workspaceCanonical retrieval store shared with Nexus Notebook.
COMPATIBILITY MATRIXDeveloper surfaces
GOVERNED INTEGRATIONS
Connectors & MCP
Connector credentials remain server-side and are never exposed to the browser. Every active connector has explicit scope, bounded execution and revocable MCP projection.
Administrator managed
CONFIGURED CONNECTORSGoverned manifests and runtime status
SERVER-SIDE CREDENTIALSActivation exposes only the capabilities declared by the accepted connector contract.
AVAILABLE ADAPTERSProvision a new integration
PROVISION REQUIREDConfiguration remains unavailable until required tenant details and contract tests are supplied.
How setup works1. Create the provider secret server-side2. Record approved tenant and endpoint3. Complete connector review before activation
HUMAN APPROVALServiceNow action requests
Microsoft Teams
Requires Entra tenant consent, Graph permissions and application access policy.
Zoom
Requires OAuth/Meeting SDK authorization and recording/transcript webhooks.
Zoho Meeting
Requires OAuth, plan capability confirmation and recording/transcript retrieval details.
GOVERNED EVIDENCE
Nexus Notebook
Create private collections, scan uploads before indexing, quarantine sensitive evidence for independent review, control access, and retrieve chunk-level citations. Semantic retrieval reports degraded until an approved embedding pack is installed.
0 sourcesRetrieval unknownGoverned evidence
N
Work with trusted knowledge
Select a collection and ask a question. Nexus Notebook retrieves available ready-source evidence before the local model answers.
GOVERNED APPLICATION ENGINEERING
Nexus One App Studio
Turn an idea into a secure internal application with a local coding model, reviewed source, isolated validation and controlled release.
BUILD WORKSPACE
Start a governed application
Create from a proven pattern or import an existing Git repository. Every source change remains reviewable before it becomes an immutable version.
⌘
Describe an applicationSelect a project, then give Nexus Coder the business outcome. Specification, design and source stay reviewable.
LOCAL model executionDURABLE build queueIMMUTABLE source versionsCONTROLLED promotion
CONTROLLED APPLICATION WORKFLOW
From project to controlled release
The authoritative client walkthrough for creating, reviewing, validating and promoting a Nexus One application. Every step corresponds to persisted platform state.
The complete App Studio workflow
Use this sequence for the client demonstration. Source, build artifact, release and approval records are separate and remain evidence-bound.
- Create or import a project.Choose a runtime and stable project identity, or import a verified Git revision.
- Complete the specification.Record outcome, users, roles, requirements, entities and acceptance criteria.
- Approve the specification.Lock the contract to its checksum.
- Approve the visual contract.Confirm page hierarchy, components and schema.
- Choose agent and model.Select complete generation or a bounded guided change.
- Generate source.A durable local job produces proposed files; nothing is accepted automatically.
- Review every generated file.Inspect the complete file and diff set.
- Accept or reject at file level.Hunk-level rejection is not implemented. Rejecting restores the file and invalidates prior validation.
- Accept the proposal as an immutable source version.The accepted checksum cannot be edited in place.
- Run validation.Record syntax, entrypoint, policy and isolated sandbox evidence.
- Deploy the exact preview.The preview artifact is built from the accepted source and manifest.
- Test the exact preview.Verify acceptance criteria, assets and interactions—not the structural design preview.
- Request publication.Submit the exact application version in Applications.
- Use a different authorized reviewer.Separation of duties prevents self-approval.
- Approve the exact checksum.The decision binds to the submitted source checksum.
- Promote the healthy release.An authorized administrator activates the approved preview.
- Verify the live application.Confirm behavior, assets, headers and exact release/version binding.
- Confirm idempotency.Retry or reload must not create duplicate versions or releases.
- Use rollback only when required.Select an earlier healthy release; rollback never edits source history.
- Restore the intended release and record evidence.Capture IDs, checksums, health and the supported rollback procedure.
Keep the records distinctAccepted source is immutable input. The build artifact is its manifested output. A release deploys that artifact. Independent approval authorizes the exact submitted checksum.
Create a project and application contract
Start with the measurable business outcome. Choose the runtime, identify users, define permissions, list core requirements and name the data entities the application owns.
A strong requirement is verifiable.Prefer “A reviewer can approve or reject a request and the decision is recorded” over “Create an approval page.”
Before approval, confirm
- Every user type has an explicit role.
- Acceptance criteria can be tested.
- No secrets, credentials or private data appear in prompts.
- The specification describes behavior, not implementation details.
Define the visual contract
Add pages and components using type: label, then define the supporting JSON data schema. The structural preview confirms information hierarchy—not final generated styling.
heading: Operations command center stat: Enterprise availability stat: Critical incidents table: Service health button: Acknowledge incident
Approve the visual contract only after the page hierarchy and data model match the specification.
Select the model, generate and review
Nexus Coder creates a complete application. Guided Coder is better for controlled changes to an existing version. Generation runs as a durable job and can recover after navigation.
- Describe visual quality, important interactions and demonstration data.
- Wait for the durable build to complete.
- Inspect every file and diff.
- Reject unsafe or incomplete source; accept only a complete desired file set.
Fix and extend an existing repository from VS Code
Use the offline-compatible extension when the application already exists in Git. v1.4 adds immutable checkpoints and interruption recovery to pinned models, isolated validation, bounded repair and evidence-bound reviews.
Install and connect
- Install the Nexus Development CA in the workstation trust store.
- Download Nexus Code Agent 1.4.1 and its SHA-256 file.
- Verify the checksum, then install the VSIX.
- Run
Nexus: Configure Applianceand complete device login in the browser.
shasum -a 256 -c nexus-code-agent-1.4.1.vsix.sha256 code --install-extension nexus-code-agent-1.4.1.vsix
Run a governed coding task
- Open the Git repository root and start a task with an approved baseline model.
- Create a checkpoint before a risky transition; resume restores the server-derived next action.
- Execute, inspect every diff and accept the immutable version.
- Run isolated validation, bounded repair if needed, then register the pushed review.
Resumable, evidence-bound development in v1.4
Checkpoints bind durable task, job, proposal, validation and review state. After interruption, Nexus restores the next permitted action without repeating completed work. Reviews still require a different authenticated reviewer; merge and deployment remain separate decisions.
Recovery never bypasses approval.v1.4 resumes only from durable Nexus state, requires proposal acceptance before repaired source becomes a version, asks separately before pushing, and preserves independent review and deployment gates.
Run your first governed coding task
Start from a clean, committed Git branch. Nexus does not replace Git: it creates a validated immutable version first, then an isolated review branch.
- Open the repository root.Use File → Open Folder on the Git root and confirm the intended branch in VS Code’s status bar.
- Connect and sign in.Open the Command Palette (
⇧⌘Pon macOS orCtrl+Shift+Pelsewhere), runNexus: Check Connection, then use device login if requested. - Import the baseline.Run
Nexus: Import Current Repository. Choose runtime, repository name, approved remote URL and base branch. Nexus records the commit and a bounded, sensitive-file-filtered snapshot. - Start a precise task.Run
Nexus: Start Coding Task, select an approved model, describe the behavior, constraints and tests, then read and approve the plan. - Execute and inspect.Choose Execute now. When the durable job finishes, inspect every file and diff; accept only the complete desired proposal as an immutable version.
- Validate and apply.Run the appropriate isolated toolchain validation, inspect its evidence, then choose Apply to workspace. Only validated matching paths are overwritten after confirmation.
- Create a review branch.Run
Nexus: Prepare Validated Git Review. It uses a sibling worktree, runs approved checks, and commits only validated paths tonexus/<task>-<title>. - Push, review, merge separately.Push only to an approved
origin. Nexus registers the evidence, but an independent reviewer, merge decision and protected deployment approval remain required.
Copy-and-adapt task request
Change only [files or feature area]. Desired behavior: [observable user outcome] Must preserve: [existing behavior] Constraints: no external service, CDN, secret or unrelated-file change. Acceptance checks: [specific success and edge-case checks]
Baseline discipline matters.Commit or safely stash work you cannot reproduce before importing. Nexus preserves unrelated workspace changes, but a clean baseline makes the snapshot, diff and review branch auditable.
Which command to run, and when
| Command | When to use it | Expected result |
|---|---|---|
Nexus: Configure Appliance | First installation or appliance address change. | Stores the HTTPS appliance URL; it does not sign you in. |
Nexus: Sign In with Device Login | Connection requires authentication. | Opens browser login; tokens stay in VS Code SecretStorage. |
Nexus: Import Current Repository | Before the first task or after changing project baseline. | Creates a bounded snapshot and records the base commit. |
Nexus: Continue Coding Task | The plan needs a clarification or narrower scope. | Creates a revised plan requiring fresh approval. |
Nexus: Create Resumable Task Checkpoint | Before a handoff, risky transition or interruption. | Stores durable evidence without duplicating source or executing code. |
Nexus: Resume Coding Task | VS Code restarted, a job failed, or work was handed over. | Restores the next permitted action such as review, retry validation or Git review. |
Nexus: Show Local Validation Evidence | A test passed or failed and a reviewer needs details. | Shows retained statuses and output hashes; raw output remains local. |
Nexus: Prepare Validated Git Review | Validation passed and the change is ready for Git review. | Creates isolated worktree, commit and optional review-branch push. |
What Nexus will never do automaticallyIt does not approve its own change, merge a review branch, deploy to a protected target, discard unrelated local work or switch to a model whose approval changed since planning.
Recover safely from common situations
No models available or inference unavailable
Open Health Center first. Wait for inference to become ready; do not reinstall the VSIX or create duplicate tasks while appliance inference is unavailable.
Device login or certificate warning
Install the Nexus Development CA in the operating-system trust store, restart VS Code, configure the appliance again, then complete device login. Never bypass a certificate warning.
VS Code closed or the task was interrupted
Reopen the same repository root and run Nexus: Resume Coding Task. Follow its displayed next action; do not rerun execution when the task is waiting for review or validation.
Isolated validation failed
Read validation evidence. Use the bounded repair option or a narrowly scoped follow-up task, accept the repair as a new immutable version, then validate again. Never edit an accepted version in place and call it validated.
Git review push failed
The local review branch and commit remain valid. Check git remote -v, network access and Git credentials, then push the created branch manually. If there is no origin, keep the local review branch only.
Apply to workspace is refused
A target file no longer matches the validated source. Preserve intended local work, inspect the diff, restore a clean baseline or create a new governed task. The refusal prevents an unreviewed mixture from being presented as validated.
Support handoff checklist
Validate, preview, approve and promote
Validation runs syntax, entrypoint, policy and isolated sandbox checks. After validation, deploy a real preview—the live preview is the exact generated application.
- Open and test the exact preview.
- Request publication.
- Have a different authorized identity approve the checksum.
- Promote the healthy approved release.
- Use release health and earlier healthy versions for rollback.
What to enter in every field
| Field | Purpose | Strong example |
|---|---|---|
| Project name | A stable business name visible in the portfolio and release records. | Enterprise Service Operations Center |
| Slug | The permanent lowercase URL identifier. Avoid versions and environments. | enterprise-service-operations |
| Runtime | Static web for dashboards; Node or Python only when the app needs a server process. | HTML / CSS / JavaScript |
| Business outcome | Who benefits, what decision improves and how success is observed. | Give operations leaders one governed view of service health and SLA exposure. |
| Users | One real persona per line. | Operations executive; Service owner; Incident commander |
| Roles and permissions | What each persona may view or change. | Service owner: acknowledge and own incidents |
| Requirements | One observable behavior per line. | List incidents with severity, owner, service and elapsed time |
| Data entities | Records owned by the app and their essential fields. | Incident: title, severity, service, owner, elapsed, status |
| Acceptance criteria | Binary tests a reviewer can perform in exact preview. | Acknowledge changes the selected incident’s visible state |
Approve the contract when
- Every user has a role.
- Every requirement has testable evidence.
- Data ownership is clear.
- No secret or personal data is present.
Revise it when
- Requirements use vague words such as “modern” or “smart.”
- Business behavior is mixed with CSS instructions.
- Change permissions are missing.
- Offline operation depends on an external service.
Choose the correct generation mode
Nexus Coder
Use for a new application or full redesign. It plans the file set and returns complete files. Your request should describe visual quality, key interactions, representative data and offline constraints.
Guided Coder
Use for a bounded change to an existing immutable version. State exactly what must change and what must remain unchanged to keep the review surface small.
An effective build request contains five parts
- Visual character: density, hierarchy, color direction and target viewport.
- Core interactions: what buttons, filters and forms must do.
- Demonstration data: records and states needed for review.
- Constraints: no external assets, no secrets and approved runtime files only.
- Completion: request the complete desired file set rather than fragments.
Durable jobsGeneration receives a persisted job ID, survives navigation and retries transient inference failures. Cancelling records the decision and prevents creation of a review proposal.
Review before accepting an immutable version
Generated source is only a proposal. Inspect the complete file set and every diff, decide at file level, then accept the resulting file set as a permanent version. Hunk-level rejection is not implemented. Rejecting a file restores it and invalidates prior validation.
Accept or reject?
Accept only when the complete source is safe and reviewable. Reject when files are missing, behavior is invented, policy is violated or the implementation materially diverges from either approved contract.
Common problems and recovery
Generation remains queued
The local worker may be busy. Keep the job ID and refresh the project; Studio reconnects automatically. Cancel only when the request is no longer required.
Generation fails after three attempts
Confirm the model is available, reduce an excessively broad request and retry. A failed durable job never creates an accepted source version.
The structural preview differs from the final application
This is expected. Structural preview validates hierarchy only. After validation and preview deployment, use “Open exact application” to inspect the generated HTML, CSS and JavaScript.
Validation fails
Review the recorded error. Typical causes are missing entrypoints, prohibited paths or extensions, syntax errors, or runtime startup failure. Generate a correction rather than bypassing validation.
Promotion reports that approval is required
The publication checksum must be approved by a different authorized identity. Confirm the approved Applications version matches the Studio source checksum.
The launch URL redirects to sign-in
This is normal. Active applications run behind the authenticated Nexus gateway. Configure access mode and explicit subjects after promotion.
The browser shows “Not Secure”
Install the Nexus Development CA in that workstation and browser trust store, then restart the browser. Do not bypass certificate warnings. The extension also requires valid HTTPS and never disables TLS verification.
Prepare Validated Git Review refuses to continue
Open the Git repository root, apply the accepted Nexus version, and confirm every affected file still matches it. If validation fails, inspect Nexus: Show Local Validation Evidence, fix the issue through a new governed task, and do not bypass the check.
Rollback procedure
- Open Release history and select an earlier healthy or superseded release.
- Verify its version checksum and recorded health.
- Choose Roll back and wait for the target to become active.
- Run Live health and test the authenticated launch URL.
Enterprise operations dashboard
Business outcome
Give operations leaders one governed view of service health, critical incidents, SLA exposure and accountable response.
Users and permissions
- Operations executive: view enterprise health and risk.
- Service owner: acknowledge and own incidents.
- Incident commander: update severity and resolution state.
Build request
Build a polished, information-dense enterprise operations command center. Use dark navy and violet styling, strong typography, four KPI cards, a service-health matrix, a critical-incident table, owner indicators, SLA risk states and a working local acknowledge interaction. Use realistic demonstration data and no external assets.
Acceptance walkthrough
- Confirm the title and four KPIs appear clearly at the target desktop viewport.
- Verify incidents show severity, service, owner, elapsed time and status.
- Acknowledge an incident and confirm its visible state changes.
- Confirm no remote asset is required after reload.
- Request approval only after the exact preview passes.
Definition of doneGeneration is not completion. The application is done when reviewed source passes validation, exact preview satisfies acceptance criteria, an independent reviewer approves the checksum and the promoted release reports healthy.
GOVERNED LIFECYCLE
Application catalogue
Versions require independent approval. Deployment execution remains locked until the signed offline Pack Manager is installed.
+ Register application
OFFLINE SUPPLY CHAIN
Verified packs
Only schema-valid, inventory-complete and trust-store-signed media appears here. Application remains fail-closed pending controller qualification.
Inspect mediaSchema and inventory
Verify signatureOffline trust store
Check entitlementFail-closed license
Qualify controllerCompatibility evidence
ActivateAudited lifecycle
OFFLINE SUPPLY CHAINPack inventory
Loading administrative capability…
ASSIGNED · INDEPENDENT · AUDITED
Assigned Reviews
Only reviews assigned to this identity are actionable. Source creation, execution, deployment and promotion remain separate and unavailable to the reviewer role.
CODE AGENTEvidence-bound code reviews
APPLICATION RELEASESSubmitted application versions
ROLE-AWARE ACCESS
This workspace is not available to your role
The menu and route use the same capability policy. Server authorization remains authoritative for every API request.
Return Home404 · PAGE NOT FOUND
This Nexus page does not exist
The address is not mapped to an available workspace, administration page, or help resource. Check the link or return to a known capability.
Loading Help content…
COST + CAPACITY GOVERNANCE
Inference usage
Provider-reported tokens are authoritative. Responses without usage metadata remain visible as unreported and are never presented as measured cost.
OPERATING CONTROLSAdministration command centerMove from status to the appropriate governed control surface.
H
Health CenterInspect authoritative dependency checks and live inference latency.
Open →
AGovernance & AuditSearch append-only actor, action, resource and evidence records.
Open →
UUsage & QuotasReview metered consumption and assign subject-level limits.
Open →
PPack ManagerReview signed offline media, compatibility and activation state.
Open →
Authoritative Readiness comes from mandatory probesAppend-only Governance evidence remains retainedProvider reported Tokens are never estimated as measured cost
LIVE DEPENDENCIESHealth CenterNot yet observed
APPEND-ONLY EVIDENCEGovernance & Audit
0 events
| Time | Actor | Action | Resource | Evidence |
|---|
MONTHLY CONSUMPTIONUser token usageUnderstand workforce consumption and assign limits without working with identity IDs.
Metering and service-identity details
GOVERNED MARKETPLACE
Reusable templates
Immutable, checksum-evidenced template versions require independent publication review. Installation creates an owned copy and rechecks its entitlement.
+ Create reusable template
DOCUMENT DIGITIZATION
Create a searchable record
Upload scans or PDFs, check the extracted information, then save or send the result to a Notebook.
UPLOAD
Add your documents
PDF or image · up to 50 files · 20 MiB per batch
Drop documents here or choose filesFiles are malware-screened and processed inside this appliance.
RECORDSSaved documentsSearch and open records
ADMINISTRATIONGovernance and operationsPolicies, batches, integrations, and recovery
ENTERPRISE CONTROLS
Governance and operations
Extraction and retention
The exact active template version and retention deadline are bound to each saved record.
Work queues and SLA
Batches expose priority, due time, progress and failure counts.
DMS and signing readiness
External writes and signatures remain unavailable until qualified connectors and certificate secrets exist.
Recovery validation
A passing result requires database, object, and independent restore-test evidence.
GOVERNED DOCUMENT REVIEW
Document Compare
Upload a baseline and candidate to identify meaningful changes with persisted, exportable evidence.