Project boundary
Which company, client, site or operational environment owns the mission?
SECURITY + CONTROL
Real action requires
Real action requires
clear authority.
Nexus is designed around project boundaries, selective permission, independent oversight and evidence. A capability can be useful without receiving unrestricted access to everything behind it.
The worker does not need the keys to the building.
A mission receives the specific capability and authority needed for the defined objective. Access remains attached to project, resource, action and time—not to a vague belief that an AI should be trusted everywhere.
Resource scope
Which files, records, accounts and systems belong to the work?
Action authority
May Nexus inspect, prepare, execute, publish, send or approve?
Scale control
Is the number or value of affected items consistent with the objective?
Sensitive data
Can the mission finish without exposing or moving unnecessary information?
Decision boundary
Does policy, preference, ambiguity or risk require a person?
Different actions receive different permission.
One project can allow routine formatting repairs, require approval for prices, keep customer communication locked and always reserve publication for a named person.
Independent questions protect the mission.
Oversight evaluates the objective, permission, scale, information exposure and scope before sensitive work continues.
Objective match
Does the proposed action genuinely contribute to the user’s stated result?
Permission match
Is this action inside the project and mission authority?
Unexpected scale
Has the affected volume changed beyond the approved interpretation?
Sensitive movement
Is information being exposed, copied or transferred unnecessarily?
Project isolation
Is a worker attempting to use another project or resource?
Scope change
Has new information materially changed the mission that was approved?
The mission records what actually happened.
A result is accompanied by the information needed to inspect, review and correct the work.
Before-state
The relevant starting state, identity and scope.
Action record
Which capability acted, under which authority and at what time.
Change evidence
Diffs, manifests, affected records, outputs and side effects.
Review findings
What an independent reviewer checked and corrected.
Human decisions
The exact choice, supporting context and decision owner.
Verified result
The final state measured against the original objective.
Trust is earned through observable behaviour.
Nexus does not ask users to infer safety from confident language. The interface shows the objective, authority, work state, decisions, checks and actual result.
Explicit objective
Show what Nexus believes the user wants before major work begins.
Specific approval
Explain the exact action and consequence that a person is approving.
State distinction
Keep inspected, prepared, executed, checked and completed separate.
Actual result
Report what changed—not merely what was attempted.
Visible interruption
Stop and explain when evidence, authority or scope is insufficient.
Durable history
Preserve the information required to understand and review the action later.
One place for security, operational and business review.
Mission history connects the human objective with the systems used, the authority granted, the work completed, the exceptions raised and the evidence returned.
OPERATIONAL LOGICWhat Nexus is actually doing behind the mission.
01Interpret & authoriseLoad the project rules, confirm the requested outcome and fix the permitted website scope.
02Connect & discoverOpen the authorised HTTPS, SFTP and content connections; identify the active web root and map URLs to their sources.
03Read & compareWalk the relevant files, pages, forms and records; compare the current state with the accepted project rules.
04Protect & executeCreate a snapshot and change manifest, then perform only the changes that fall inside mission authority.
05Read back & verifyRe-read server sources and public URLs; test the affected paths and compare the result with the objective.
06Record & continueStore evidence, decisions, changed items and rollback references in the continuing project history.
MISSION ACTIVITYConnections, inspection, actions and proof in one operational record.
15 / 15 eventsFind what changed before the site failed. Compare it with the last known-good state, prepare the smallest safe repair, and stop if the evidence does not support an automatic restore.
COMMAND
Project objective2%
I understand the requested outcome. I am fixing the scope, constraints, authority and evidence required before work begins.
INTERPRET
Scope · constraints · authority · success test6%
Incident authority permits investigation and staging repair. Production changes remain limited to the smallest verified recovery package.
AUTHORISE
Project permissions · capability scope · blocked actions11%
Connected monitoring, server logs, website SFTP, database diagnostics and the snapshot store. The affected domain and failure window were confirmed.
CONNECT
Monitoring / logs + SFTP site + Database17%
Preserved the current failed state and verified the last known-good snapshot before comparing or restoring anything.
CHECKPOINT
Snapshot store22%
The failure time, recent deployment history, public symptoms, current files and last known-good snapshot were loaded.
LOAD CONTEXT
Project rules · history · accepted decisions28%
The incident worker is reconstructing the change timeline, comparing file hashes and database settings, and following the failing request through logs and affected code paths.
INDEX
Files · pages · records · linked business data34%
Forty-two changed items were compared. Three changes correlate with the failure window and affected route.
DISCOVER
Authorised working environment41%
Two changed files form one high-confidence causal set. A third database setting remains plausible but unproven.
PLAN
Work graph · normal cases · exceptions51%
The two-file repair was prepared from the last known-good state with a before-state package and exact diff.
EXECUTE
Authorised change set64%
The Recovery Reviewer reproduced the failure path, checked the repair in staging and confirmed that unrelated changes remain intact.
VERIFY
Result against objective and project rules77%
The mission remains inside the approved scope and authority. Sensitive actions outside that boundary remain locked.
CONTROL
Permission and scope boundary84%
One unresolved risk remains: restore the database setting as well, or deploy the verified two-file repair and continue monitoring.
DECIDE
Human attention queue89%
The smallest evidence-supported recovery is ready. Nexus stopped before extending the repair beyond what the incident evidence proves.
RESULT
Verified mission state92%
Mission scope, evidence, decisions, changes and verification have been attached to the project for the next command.
STORE
Project history · evidence · decisions92%
DECISION REQUIREDChoose the recovery boundary
VERIFICATION
- Repair diff contains only the two causal files.
- The failure path passes in the checked environment.
- Unrelated recent changes remain intact.
- Before-state and recovery packages are preserved.
Give AI useful capability without giving it vague authority.
Define the project, mission, resources and actions. Nexus keeps those boundaries visible from objective to result.