ATLAS

The problem

Enterprise architecture information is spread across diagrams, presentations, decisions, standards, spreadsheets, project documents, repositories and individual knowledge.

The difficulty is not simply storing those artefacts. It is preserving the relationships between them, and understanding the strength of the evidence behind an architectural statement.

Atlas explores whether that knowledge becomes more useful when capabilities, patterns, technologies, controls, decisions, claims and evidence are treated as related objects rather than isolated documents.

Can the repository retain the reasoning?

Can an architecture repository become more useful if it records not only architecture objects, but also the explicit relationships, evidence, provenance and uncertainty behind them?

The investigation focuses on making an architectural position inspectable: what it refers to, what supports it, what challenges it and what still needs to be established.

A structure for asking better questions

The central reading path is simple: Problem → Capability → Pattern → Technology / Implementation → Control → Evidence. Start with a need, identify the ability required, explore a reusable approach, examine its possible realisation and controls, then ask what evidence supports the position.

Decisions and claims capture the position being taken. Concepts and principles help explain its meaning. Questions, assessments and gaps record what needs scrutiny. The wider model considers these distinctions; the public Build exposes a deliberately smaller selection.

Architecture is in the relationships

A normal hyperlink is navigation. An Atlas relationship is an explicitly authored architectural statement. Its type matters.

depends-on

Records a dependency to review.

integrates-with

Records an interaction, without automatically establishing a dependency.

governed-by

Connects an object to a stated control.

supports / contradicts

Connects evidence to the position it supports or challenges.

supersedes

Preserves the link between a previous decision and its replacement.

The demonstrator follows these authored links. A line on the graph is not proof that the corresponding dependency exists in a deployed system.

Evidence is not the same as confidence

A source can be authoritative about what was approved without proving what was implemented. A claim can sound convincing while its supporting evidence remains narrow. Atlas keeps those distinctions visible.

A useful repository can leave a question open

These states describe the position within a stated scope, not a permanent verdict. The public selection illustrates some of them; it is not a complete inventory of the wider model.

Known

Supported by accepted evidence within its stated scope.

Known unknown

The question matters, but the evidence needed to answer it is still missing.

Hypothesis

A proposed explanation or position that still needs testing.

Disputed

Available evidence supports competing interpretations.

Unknown

There is not enough information to take a position.

Not applicable

The question does not apply within the defined scope, with the reason recorded.

Patterns as reusable architecture knowledge

A pattern describes responsibilities, boundaries, decisions, controls, failure modes, evidence and observability considerations, and possible technology realisations. It helps structure a design discussion; it is not a certificate of suitability.

The published Build contains three existing references: Consequential Agent Action, Enterprise RAG and Agentic Workflow. Their diagrams and detailed views retain their own illustrative scenarios, separate from the fictional Asteron evidence.

The broader research scope also includes Event-Driven Autonomous Operations, Secure AI / Sensitive Data and Model Context Protocol. Those topics are not part of the three-pattern public selection shown here. Availability must not be mistaken for production proof.

What the investigation tested

The work tested how a small, curated architecture could remain navigable without losing the basis for its statements.

• Structure: typed architecture metadata, stable object IDs and a controlled relationship vocabulary.
• Pattern representation: connected references with diagrams, decisions, controls and failure modes.
• Evidence: source references, provenance and limitations kept separate from claim confidence.
• Competing positions: authored support and contradiction, retained superseded decisions and explicit known unknowns.
• Exploration: deterministic search, relationship traversal and a public-safe graph over a fixed fictional model.

Automated checks verify the selected model’s identities, relationship endpoints, scoped traversal and search. Browser checks exercise navigation, evidence selection and responsive presentation. These checks establish behaviour in this demonstrator, not the completeness of an enterprise inventory or an improvement in real-world decision quality.

What we learned

The bounded work supports a set of design lessons. Broader usefulness still needs evaluation in real architecture work.

• Explicit relationships make the reasoning easier to inspect. The visitor can distinguish an interaction from a dependency instead of reading meaning into a link.
• Evidence belongs against the claim it bears on. Storing it beside a diagram leaves its relevance unclear.
• Authority and confidence need separate treatment. Neither is a shortcut to implementation proof.
• Decision history matters. A superseded position explains what changed and why; deleting it loses that context.
• Unknown and disputed states are useful information. They show where further evidence is needed.
• A graph helps exploration, within limits. It makes authored relationships visible but cannot establish deployed dependencies.
• Credible scope is more useful than implied automation. Curated evidence can be challenged without claiming automatic conflict discovery or complete impact analysis.

What Atlas does not claim

The current public Build is a read-only fictional demonstrator: 33 architecture objects, 50 authored relationships and three selected pattern references. Its organisations, decisions and evidence are invented.

• A complete enterprise inventory
• Automatic conflict detection or general graph reasoning
• Automatic impact analysis or retirement simulation
• A conversational copilot or automatic architecture recommendations
• Proof that a diagrammed dependency exists in production

Recorded dependency traversal is a bounded review aid. The demonstrator does not ingest a live estate, infer missing links or validate a real deployment. No private corpus, client architecture or personal learning records are published.

Can the structure help real architecture work?

The next question is whether this structure helps people recover context, challenge a position and identify missing evidence in representative architecture tasks. That would need independent review against a known set of sources, with mistakes and missing coverage recorded.

The demonstrator is a way to inspect the design before claiming that wider benefit.