-
-
Verity scenario: Atlas detects a missing DataHub owner, prepares a human-confirmed repair proposal, and requires a fresh re-read.
-
Nexus Atlas architecture: a context fabric connecting project memory, decisions, governed DataHub assets, and verified actions.
-
Atlas Desk surfaces the project state, valid decisions, stale evidence, agent conflict, and missing ownership at a glance.
-
Atlas Map traces the route between the Verity project, governed DataHub assets, evidence, decisions, and broken ownership.
-
Evidence and Conflict traces stale records, competing agent memories, missing ownership, and the decisions affected by each signal.
-
Ownership proposal preview showing the exact DataHub operation, target asset, proposed owner, and post-write MCP re-read verification.
-
Decision and Action separates confirmed decisions, unresolved human gates, ownership risks, and the next recommended actions.
Inspiration
Returning to a long-running project can be harder than starting one.
The files usually remain, but the working context becomes fragmented: what changed, which decisions still hold, which evidence is outdated, why different agents recommended different directions, and what action is safe to take next.
Most AI assistants begin with the latest prompt. Nexus Atlas begins with the context that future work depends on.
We built Nexus Atlas to help people and agents return to interrupted work without reconstructing the entire project from scratch.
What it does
Nexus Atlas is a personal context infrastructure for restoring continuity across long-term projects.
In the current Verity re-entry scenario, Atlas helps the user understand:
- what changed during a 21-day interruption;
- which decisions are still valid;
- which evidence is stale;
- where agent recommendations conflict;
- which governed DataHub asset is missing an owner;
- and what action should happen next.
The experience is organized into connected views:
- Atlas Desk surfaces projects and context risks that need attention.
- Atlas Map connects projects, evidence, decisions, governed assets, and actions.
- Continuity Workspace restores changes, evidence chains, memory records, decisions, and recommended next steps.
- Context Inspector explains the source, state, provenance, and relationships behind each record.
- Confirmation Sheet requires human review before a consequential governance action.
Nexus Atlas does not silently resolve conflicts or mutate external state. It preserves competing agent memories, shows the supporting evidence, and keeps the final decision with the user.
How we built it
Nexus Atlas uses a provider-neutral Context Fabric to represent projects, events, decisions, actions, agent runs, external assets, relationships, provenance, and state.
Continuity findings are generated through deterministic rules. These rules identify meaningful changes, valid decisions, stale evidence, agent conflicts, missing ownership, and blocked actions before any model explanation is added.
DataHub has a separate governance role. It provides asset ownership, lineage, and metadata state, while Nexus maintains the broader project context.
For the Verity scenario, we modeled six governed DataHub Dataset assets:
- Evaluation Rubric
- Test Materials
- Benchmark v1
- Scoring Calibration
- Evaluation Results v0.4.7
- Release Readiness Evidence
A read-only MCP adapter retrieves DataHub state and overlays it onto the Nexus context. The ownership-repair path is isolated from the read path and restricted to a validated add_owners proposal for the Benchmark asset.
The governed flow is:
Read ownership
→ detect missing owner
→ prepare an exact proposal
→ request human confirmation
→ perform the allow-listed action
→ read DataHub again
→ verify the intended owner
→ close the context signal
The public GitHub Pages demo uses a deterministic fixture scenario. It demonstrates the Atlas re-entry, evidence, decision, and ownership-proposal experience without sending a DataHub request or executing a live mutation.
The interface was built with HTML, CSS, and JavaScript. Node.js powers the runtime services and validation logic, while Python supports DataHub asset ingestion and preparation.
## Challenges we ran into
The hardest part was not building another interface for project information. It was deciding what Atlas should trust, what it should only surface, and what still required human judgment.
We had to keep several states clearly separated:
- missing ownership versus an unavailable DataHub source;
- confirmed decisions versus agent recommendations;
- stale evidence versus invalid evidence;
- a successful mutation response versus a verified external state change.
We also needed to connect personal project context with governed DataHub metadata without treating DataHub as the storage layer for the user's entire context graph.
Another challenge was designing the Atlas Map. It had to make relationships visible without becoming a dense decorative graph. We focused on a small, task-specific context route where every node and broken connection has a clear source and purpose.
## Accomplishments that we're proud of
We are proud that Nexus Atlas became more than a concept or a generic AI dashboard.
We built:
- a complete Atlas Desk, Map, Workspace, Inspector, and Action flow;
- a concrete Verity re-entry scenario with meaningful project history;
- deterministic detection of stale evidence, valid decisions, agent conflicts, and missing ownership;
- a provider-neutral context model that separates personal continuity from external governance metadata;
- six governed DataHub assets with explicit lineage;
- a read-only MCP integration path;
- an isolated, allow-listed ownership-repair proposal;
- human confirmation before consequential actions;
- a read-after-write verification contract;
- and a public fixture demo that clearly distinguishes simulation from live DataHub execution.
We are especially proud that the system does not treat automation as the goal by itself. Atlas prepares an exact, traceable action and keeps the final authority with the user.
## What we learned
We learned that context continuity is not the same as storing more memory.
Useful continuity requires clear provenance, freshness, relationships, authority, and state. A record is only valuable when the system can explain where it came from, whether it is still valid, what decision depends on it, and who is allowed to change it.
We also learned that agentic systems should not automate every possible action. In many cases, the more trustworthy design is to prepare an exact proposal, show the supporting evidence, require human confirmation, and verify the result through a fresh external read.
Finally, integrating DataHub showed us the importance of separating personal project context from governed metadata. They need to work together, but they should not be treated as the same source of truth.
## What's next for Nexus Atlas
The next step is to move from the current focused Verity scenario toward a reusable continuity system for multiple long-term projects.
Our priorities are:
- complete and capture final local DataHub runtime verification;
- formalize the Context Package passed into continuing work;
- add durable outcome and memory write-back;
- expand Atlas Desk to prioritize multiple active projects;
- generalize the re-entry workflow beyond Verity;
- strengthen decision tracing and governance policies;
- add more governed data sources and connectors;
- activate the Learning and Research territories.
The long-term goal is to build a personal intelligence infrastructure where people and agents can restore context, trace decisions, continue the work, and record verified outcomes.

Log in or sign up for Devpost to join the conversation.