Architecture Knowledge Lifecycle¶

Introduction¶

Architectural knowledge isn't static. It's created in design sessions, captured in models and decisions, validated against reality, shared across teams, applied in governance, evolved as context changes, and eventually retired when it no longer applies. Each stage has different requirements, different failure modes, and different tooling needs.

Most architecture practices focus on creation and capture — drawing models, writing decisions. The later stages (validation, sharing, application, evolution, retirement) are where knowledge decays, becomes stale, or simply disappears. Understanding the full lifecycle is what separates an architecture practice that accumulates artifacts from one that maintains a living knowledge base.

This article maps the lifecycle, identifies where knowledge typically breaks down, and shows how a knowledge graph approach addresses each stage.

The lifecycle¶

graph LR
    C["Create"] --> CA["Capture"]
    CA --> V["Validate"]
    V --> S["Share"]
    S --> A["Apply"]
    A --> E["Evolve"]
    E --> R["Retire"]
    E -->|"feedback"| V
    A -->|"new insight"| C

    style C fill:#e8f4e8,stroke:#2d7a2d
    style CA fill:#ddf0dd,stroke:#2d7a2d
    style V fill:#f4f4e8,stroke:#6a6a2d
    style S fill:#e8ecf4,stroke:#2d4a7a
    style A fill:#e8e8f4,stroke:#2d2d7a
    style E fill:#f4e8f4,stroke:#7a2d7a
    style R fill:#f4e8e8,stroke:#7a2d2d

The lifecycle isn't strictly linear. Application generates new insights that feed back into creation. Evolution triggers re-validation. Retirement of one piece of knowledge often creates the need for new knowledge to replace it. But the stages are distinct enough to analyze separately.

Stage 1 — Create¶

What happens¶

Architectural knowledge is created when architects interpret data, make decisions, recognize patterns, or formulate principles. Creation happens in:

Design sessions where architects evaluate options and select approaches
Architecture reviews where proposals are assessed against principles and constraints
Incident post-mortems where failure reveals previously unknown dependencies
Strategy workshops where business direction translates into architectural implications
Technology evaluations where new capabilities are assessed against existing patterns

The knowledge produced¶

flowchart TD
    subgraph triggers["Creation Triggers"]
        T1["Design challenge"]
        T2["Architecture review"]
        T3["Incident / failure"]
        T4["Strategy change"]
        T5["Technology shift"]
    end

    subgraph outputs["Knowledge Created"]
        O1["Decision + rationale"]
        O2["New principle"]
        O3["Pattern recognition"]
        O4["Impact assessment"]
        O5["Target state update"]
    end

    T1 --> O1
    T2 --> O1 & O2
    T3 --> O3 & O4
    T4 --> O5 & O1
    T5 --> O1 & O4

Where it breaks down¶

Tacit stays tacit. The most valuable knowledge — the reasoning, the rejected alternatives, the contextual factors — often stays in the architect's head. The meeting ends, the decision is implemented, but the "why" is never externalized.
Creation without context. Knowledge created in isolation from the existing knowledge base risks contradicting established principles or duplicating existing decisions.
Timing. Knowledge is easiest to capture at the moment of creation. Every day that passes between a decision and its documentation reduces fidelity.

What helps¶

Decision records written at the point of decision, not retroactively
Templates that prompt for rationale, alternatives, and forces — not just the conclusion
Integration with the existing knowledge graph so creators can see what already exists

Stage 2 — Capture¶

What happens¶

Capture is the act of externalizing knowledge into a persistent, retrievable form. This is where tacit becomes explicit — where the reasoning in someone's head becomes a record that others can access.

Forms of capture¶

Knowledge type	Typical capture format	Knowledge graph representation
Decisions	ADR markdown, Confluence page	`ad:Decision` with forces, options, rationale
Principles	PDF document, wiki page	SHACL shapes + `ad:Principle` instances
Patterns	Pattern catalog, reference architecture	`ra:Pattern` with tactics and quality attributes
Assessments	Spreadsheet, presentation	`timefw:FitAssessment` with evidence
Dependencies	Diagram, mental model	Typed relationships (`am:serves`, `am:realizes`)
Target state	Roadmap slide, vision document	Target architecture model with transition states

The capture gap¶

graph TB
    subgraph created["Knowledge Created"]
        direction LR
        KC1["100%"]
    end

    subgraph captured_informal["Captured Informally"]
        direction LR
        KC2["~60%<br/><small>Meetings, emails, chat</small>"]
    end

    subgraph captured_formal["Captured Formally"]
        direction LR
        KC3["~25%<br/><small>Documents, models</small>"]
    end

    subgraph captured_structured["Captured as Structured Knowledge"]
        direction LR
        KC4["~5%<br/><small>Linked, typed, queryable</small>"]
    end

    created --> captured_informal --> captured_formal --> captured_structured

    style created fill:#e8f4e8,stroke:#2d7a2d
    style captured_informal fill:#f4f4e8,stroke:#6a6a2d
    style captured_formal fill:#f4ece8,stroke:#7a4a2d
    style captured_structured fill:#f4e8e8,stroke:#7a2d2d

Most organizations lose 75% of their architectural knowledge between creation and formal capture. Of what's formally captured, only a fraction is structured enough to be queryable or validatable.

Where it breaks down¶

Format fragmentation. Decisions in Confluence, models in Sparx EA, principles in SharePoint, assessments in Excel. Each captures something, but nothing connects them.
Capture overhead. If recording a decision takes 45 minutes of template-filling, architects won't do it under delivery pressure.
Missing links. A decision is captured but not linked to the elements it affects. A principle is documented but not connected to the decisions that implement it. The knowledge exists but can't be traversed.

What helps¶

Lightweight capture formats (Turtle, YAML-LD) that integrate with developer workflows
Converters that transform existing artifacts (ArchiMate XML, Backstage YAML) into the knowledge graph automatically
Explicit linking at capture time — every decision must reference affected elements, every assessment must reference its subject

Stage 3 — Validate¶

What happens¶

Validation checks whether captured knowledge is consistent, complete, and aligned with reality. This is where errors, contradictions, and staleness are detected.

Validation dimensions¶

flowchart TD
    subgraph validation["Validation Dimensions"]
        V1["Internal consistency<br/><small>Do decisions contradict<br/>each other?</small>"]
        V2["Completeness<br/><small>Are required elements<br/>present?</small>"]
        V3["Conformance<br/><small>Does it follow the<br/>metamodel rules?</small>"]
        V4["Currency<br/><small>Does it match<br/>current reality?</small>"]
        V5["Coherence<br/><small>Does it align with<br/>principles and strategy?</small>"]
    end

    subgraph mechanisms["Validation Mechanisms"]
        M1["SHACL shapes"]
        M2["SPARQL queries"]
        M3["Runtime reconciliation"]
        M4["Peer review"]
        M5["Automated discovery"]
    end

    V1 --> M1 & M2
    V2 --> M1
    V3 --> M1
    V4 --> M3 & M5
    V5 --> M2 & M4

Automated vs human validation¶

Some validation is automatable:

Structural completeness — every application has an owner, every decision has a rationale (SHACL)
Relationship validity — ArchiMate relationship rules, metamodel constraints (SHACL)
Cross-reference integrity — decisions reference elements that exist, assessments reference valid subjects (SPARQL)
Staleness detection — elements not updated in 12 months, decisions with expired review dates (SPARQL)

Some requires human judgment:

Semantic accuracy — does the model actually reflect reality?
Rationale quality — is the decision rationale sufficient for future architects to understand the choice?
Strategic alignment — does the target state still align with business direction?
Pattern applicability — is this pattern still appropriate given technology evolution?

Where it breaks down¶

Validation never runs. Models are created but never checked. Decisions are written but never reviewed. The knowledge base accumulates errors silently.
Validation without consequence. Violations are detected but not acted on. The dashboard shows 200 warnings that nobody addresses.
Point-in-time validation. Knowledge is validated once at creation but never re-validated as context changes.

What helps¶

SHACL validation in CI/CD — every commit is checked, violations block merge
Scheduled SPARQL queries that detect staleness and inconsistency
Governance workflows that route violations to responsible parties
Severity levels (sh:Warning vs sh:Violation) that distinguish "should fix" from "must fix"

What happens¶

Sharing makes knowledge accessible to the people who need it, in formats they can consume. This is the "last mile" problem — knowledge exists but doesn't reach its audience.

Audiences and formats¶

flowchart TD
    KG["Knowledge Graph<br/><small>Single source of truth</small>"]

    KG --> G1["Executives<br/><small>Capability maps,<br/>investment dashboards</small>"]
    KG --> G2["Architects<br/><small>SPARQL workbench,<br/>model navigator</small>"]
    KG --> G3["Developers<br/><small>Markdown docs,<br/>API specs, ADRs</small>"]
    KG --> G4["Compliance<br/><small>Governance reports,<br/>audit trails</small>"]
    KG --> G5["AI Agents<br/><small>MCP server,<br/>natural language</small>"]

    style KG fill:#e8f4e8,stroke:#2d7a2d

The key insight: different stakeholders need different views of the same knowledge. An executive doesn't need SPARQL. A developer doesn't need a capability heat map. But both need access to the same underlying knowledge — just rendered differently.

Architecture knowledge is most valuable when shared broadly, but most architecture practices share narrowly:

Models stay in EA tools that only architects access
Decisions stay in architecture wikis that developers don't read
Principles stay in governance documents that nobody references during design
Assessments stay in review presentations that are forgotten after the meeting

Where it breaks down¶

Format lock-in. Knowledge captured in proprietary tool formats can't be shared without the tool license.
Push vs pull. Architecture teams push documents at stakeholders. Stakeholders need to pull knowledge at the moment of need — during design, during incidents, during planning.
Staleness at the edge. Even when knowledge is shared, copies diverge from the source. The exported PDF becomes stale the moment the model changes.

What helps¶

Generate, don't copy. Stakeholder views are generated from the graph on demand, not exported as static snapshots.
Multiple access patterns: SPARQL for architects, MCP for AI agents, generated Markdown for developers, interactive dashboards for executives.
Single source of truth with generated views — the graph is authoritative, everything else is a projection.

Stage 5 — Apply¶

What happens¶

Application is where knowledge influences decisions and actions. This is the stage that justifies the entire lifecycle — if knowledge isn't applied, the effort of creating, capturing, validating, and sharing it is wasted.

Application patterns¶

flowchart LR
    subgraph knowledge["Available Knowledge"]
        P["Principles"]
        D["Decisions"]
        PA["Patterns"]
        A["Assessments"]
    end

    subgraph application["Application Contexts"]
        A1["Design review<br/><small>Does this proposal<br/>align with principles?</small>"]
        A2["Technology selection<br/><small>What patterns apply?<br/>What was decided before?</small>"]
        A3["Portfolio planning<br/><small>What should we<br/>invest/migrate/eliminate?</small>"]
        A4["Incident response<br/><small>What depends on<br/>this failing component?</small>"]
        A5["Onboarding<br/><small>Why is the system<br/>designed this way?</small>"]
    end

    P --> A1
    D --> A2 & A5
    PA --> A2
    A --> A3
    P & D --> A4

    style knowledge fill:#e8f4e8,stroke:#2d7a2d
    style application fill:#e8e8f4,stroke:#2d2d7a

Active vs passive application¶

Passive application — knowledge is available for people to consult when they think to look for it. This depends on people knowing the knowledge exists and where to find it.

Active application — knowledge is surfaced automatically at the point of need:

SHACL validation rejects a design that violates a principle before it's merged
An AI agent surfaces relevant decisions when an architect starts working on a related problem
A governance workflow triggers when a component enters a lifecycle state that requires review
Impact analysis runs automatically when a decommission proposal is submitted

Active application is where knowledge graphs outperform document-based knowledge management. The graph can be queried programmatically, integrated into workflows, and surfaced by AI agents — without requiring humans to remember where to look.

Where it breaks down¶

Knowledge exists but isn't found. The decision was recorded three years ago. Nobody on the current team knows it exists. The same decision is re-debated from scratch.
Knowledge is found but not trusted. The principle was written in 2019. Is it still valid? Nobody knows, so it's ignored.
Knowledge is applied inconsistently. One team follows the pattern; another team doesn't know about it. Inconsistency accumulates.

What helps¶

Proactive surfacing: AI agents that retrieve relevant decisions and principles when architects work on related elements
Automated governance: SHACL shapes that enforce principles without requiring human memory
Provenance and currency metadata: every piece of knowledge has a last-reviewed date and responsible party

Stage 6 — Evolve¶

What happens¶

Evolution is the deliberate update of knowledge as context changes. Technology shifts, business strategy pivots, incidents reveal new information, regulations change. Knowledge that was correct yesterday may be wrong today.

Evolution triggers¶

flowchart TD
    subgraph triggers["Evolution Triggers"]
        T1["Technology change<br/><small>New platform, deprecated library</small>"]
        T2["Business pivot<br/><small>New market, acquisition, divestiture</small>"]
        T3["Incident learning<br/><small>Failure reveals unknown dependency</small>"]
        T4["Regulation change<br/><small>New compliance requirement</small>"]
        T5["Scale change<br/><small>Growth invalidates assumptions</small>"]
        T6["Decision review<br/><small>Scheduled reassessment</small>"]
    end

    subgraph actions["Evolution Actions"]
        A1["Supersede decision<br/><small>New decision replaces old</small>"]
        A2["Update assessment<br/><small>Reclassify in TIME/lifecycle</small>"]
        A3["Refine principle<br/><small>Add exception or constraint</small>"]
        A4["Extend model<br/><small>Add elements, relationships</small>"]
        A5["Deprecate pattern<br/><small>Mark as no longer recommended</small>"]
    end

    T1 --> A1 & A5
    T2 --> A2 & A4
    T3 --> A4 & A1
    T4 --> A3 & A1
    T5 --> A1 & A2
    T6 --> A1 & A2 & A3

    style triggers fill:#f4e8f4,stroke:#7a2d7a
    style actions fill:#e8f4e8,stroke:#2d7a2d

Evolution vs decay¶

There's a critical difference between deliberate evolution and passive decay:

Evolution is intentional: "We reviewed Decision-042 and it no longer applies because the constraint it addressed has been removed. Superseded by Decision-089."
Decay is neglect: Decision-042 silently becomes irrelevant. Nobody marks it as superseded. New architects find it and don't know whether to follow it.

A healthy knowledge lifecycle has explicit evolution. An unhealthy one has silent decay.

The versioning problem¶

When knowledge evolves, what happens to the old version?

Decisions should be superseded, not deleted. The old decision and its rationale remain as history — future architects may need to understand why something was done differently before.
Models should maintain temporal state. The current-state model and target-state model are both valid — they represent different points in time.
Principles should be versioned with effective dates. A principle that changes should show its history.
Assessments should be timestamped. A TIME classification from 2023 may no longer be valid in 2026.

ex:decision-042 a ad:Decision ;
    ad:status ad:Superseded ;
    ad:supersededBy ex:decision-089 ;
    ad:supersededDate "2026-03-15"^^xsd:date ;
    ad:rationale "Event-driven selected for payment domain..." .

ex:decision-089 a ad:Decision ;
    ad:status ad:Accepted ;
    ad:supersedes ex:decision-042 ;
    ad:rationale "Synchronous gRPC now preferred for payment domain 
                  because latency requirements tightened to <10ms P99 
                  and the event-driven approach couldn't guarantee ordering..." .

Where it breaks down¶

No review cadence. Knowledge is created but never revisited. Decisions from 2019 remain "Accepted" even though the world has changed.
Evolution without trace. The model is updated but the reason for the change isn't recorded. Future architects see the current state but not the journey.
Partial evolution. A decision is superseded but the SHACL shapes that enforced it aren't updated. The principle document changes but the validation rules don't.

What helps¶

Scheduled review dates on decisions and assessments (ad:reviewDate)
SPARQL queries that surface knowledge past its review date
Supersession chains that preserve history while clearly marking current state
CI/CD that detects inconsistencies between decisions and their implementing SHACL shapes

Stage 7 — Retire¶

What happens¶

Retirement is the deliberate removal of knowledge from active use. Not deletion — retirement. The knowledge remains accessible for historical reference but is clearly marked as no longer applicable.

What gets retired¶

Decisions about systems that no longer exist
Principles that have been fully superseded
Patterns that are no longer recommended
Assessments of decommissioned applications
Target states that have been achieved (or abandoned)

Retirement vs deletion¶

flowchart LR
    subgraph wrong["Anti-pattern: Deletion"]
        D1["Decision exists"] --> D2["System decommissioned"] --> D3["Decision deleted"]
        D3 --> D4["❌ History lost<br/>Why was it built<br/>this way?"]
    end

    subgraph right["Correct: Retirement"]
        R1["Decision exists"] --> R2["System decommissioned"] --> R3["Decision retired"]
        R3 --> R4["✓ History preserved<br/>Excluded from active<br/>governance"]
    end

    style wrong fill:#f4e8e8,stroke:#7a2d2d
    style right fill:#e8f4e8,stroke:#2d7a2d

Retired knowledge has value:

Institutional memory — why was the previous system designed that way? What went wrong?
Pattern mining — which decisions led to good outcomes? Which led to problems?
Onboarding — new architects can trace the evolution of the architecture
Audit — regulatory requirements may demand historical records

Where it breaks down¶

Nothing is ever retired. The knowledge base grows indefinitely. Active and historical knowledge are mixed. Architects can't distinguish current guidance from obsolete records.
Retirement without marking. Old decisions are "archived" by moving them to a folder nobody checks, without updating their status in the graph.
Cascading retirement. When a system is decommissioned, all related decisions, assessments, and relationships should be retired. In practice, orphaned knowledge accumulates.

What helps¶

Explicit retirement status (ad:status ad:Retired, arch:lifecycleState arch:Decommissioned)
SPARQL queries that exclude retired knowledge from active governance
Cascading retirement workflows: when an element is retired, surface all related knowledge for review
Separate active and historical views — the default view shows only active knowledge

The full picture¶

flowchart TD
    subgraph lifecycle["Architecture Knowledge Lifecycle"]
        direction LR
        C["Create<br/><small>Design sessions,<br/>reviews, incidents</small>"]
        CA["Capture<br/><small>Decisions, models,<br/>principles, patterns</small>"]
        V["Validate<br/><small>SHACL, SPARQL,<br/>peer review</small>"]
        S["Share<br/><small>Generated views,<br/>MCP, dashboards</small>"]
        A["Apply<br/><small>Governance, design,<br/>planning, AI agents</small>"]
        E["Evolve<br/><small>Supersede, update,<br/>version, refine</small>"]
        R["Retire<br/><small>Mark inactive,<br/>preserve history</small>"]
    end

    C --> CA --> V --> S --> A --> E
    E --> R
    E -.->|"re-validate"| V
    A -.->|"new insight"| C
    R -.->|"replacement needed"| C

    subgraph tooling["Linked.Archi Tooling at Each Stage"]
        direction LR
        TC["Converters<br/>Templates"]
        TCA["Turtle/YAML-LD<br/>OWL ontologies"]
        TV["SHACL shapes<br/>CI/CD pipeline"]
        TS["Generators<br/>MCP server"]
        TA["SPARQL queries<br/>AI agents"]
        TE["Versioned IRIs<br/>Supersession"]
        TR["Lifecycle states<br/>Archive queries"]
    end

    C ~~~ TC
    CA ~~~ TCA
    V ~~~ TV
    S ~~~ TS
    A ~~~ TA
    E ~~~ TE
    R ~~~ TR

    style lifecycle fill:#f9f9f9,stroke:#666
    style tooling fill:#e8f4e8,stroke:#2d7a2d

Lifecycle health indicators¶

How do you know if your architecture knowledge lifecycle is healthy? These indicators map to each stage:

Stage	Healthy	Unhealthy
Create	Decisions recorded at point of decision; rationale includes alternatives	Decisions reconstructed months later; rationale is "we decided X"
Capture	Structured, linked, queryable; integrated with development workflow	Scattered across tools; unlinked documents; manual effort to record
Validate	Automated in CI/CD; violations addressed within days	Never validated; or validated but violations ignored
Share	Generated views for each audience; knowledge found at point of need	Locked in EA tools; shared only via presentations
Apply	Principles enforced automatically; AI surfaces relevant knowledge	Principles exist but aren't checked; knowledge rediscovered by accident
Evolve	Scheduled reviews; explicit supersession; versioned history	No review cadence; silent staleness; "is this still valid?"
Retire	Explicit retirement; history preserved; cascading cleanup	Nothing retired; active and obsolete mixed; orphaned knowledge

The decay curve¶

Without active lifecycle management, architectural knowledge decays predictably:

graph LR
    subgraph decay["Knowledge Decay Without Lifecycle Management"]
        direction TB
        M0["Month 0<br/>Created"] --> M3["Month 3<br/>~90% accurate"]
        M3 --> M6["Month 6<br/>~70% accurate"]
        M6 --> M12["Month 12<br/>~50% accurate"]
        M12 --> M24["Month 24<br/>~30% accurate"]
        M24 --> M36["Month 36<br/>Unreliable"]
    end

    style M0 fill:#e8f4e8,stroke:#2d7a2d
    style M3 fill:#ecf4e8,stroke:#4a7a2d
    style M6 fill:#f4f4e8,stroke:#6a6a2d
    style M12 fill:#f4ece8,stroke:#7a4a2d
    style M24 fill:#f4e8e8,stroke:#7a2d2d
    style M36 fill:#f0d0d0,stroke:#7a2d2d

The decay isn't uniform. Different knowledge types decay at different rates:

Runtime dependencies decay fastest — infrastructure changes weekly
Application inventory decays monthly — new services, decommissions
Capability maps decay quarterly — organizational restructuring
Architecture principles decay slowly — fundamental guidance is durable
Decision rationale doesn't decay — the reasoning was valid at the time, even if the decision is later superseded

This means validation cadence should match decay rate. Runtime dependencies need continuous reconciliation. Principles need annual review. Decision rationale needs no re-validation — only supersession when context changes.

How Linked.Archi supports each stage¶

Stage	Mechanism	How it works
Create	Templates, ontology structure	Decision templates prompt for forces, options, rationale. The ontology structure makes it clear what needs to be recorded.
Capture	OWL ontologies, Turtle syntax, converters	Knowledge is captured as RDF — typed, linked, queryable from the start. Converters transform existing artifacts automatically.
Validate	SHACL shapes, CI/CD integration	Validation runs on every commit. Completeness, consistency, and conformance are checked automatically.
Share	Generators, MCP server, SPARQL	Multiple output formats from a single source. Each audience gets their preferred view. AI agents access the graph directly.
Apply	SPARQL queries, SHACL governance, AI agents	Principles are enforced as SHACL constraints. AI agents surface relevant knowledge at point of need. Impact queries answer "what if?"
Evolve	Supersession predicates, versioned IRIs, review dates	`ad:supersededBy` chains preserve history. `ad:reviewDate` triggers re-evaluation. Versioned ontology IRIs track schema evolution.
Retire	Lifecycle states, archive queries	`arch:lifecycleState` marks retired elements. Default queries exclude retired knowledge. History remains accessible.

Relationship to the data/knowledge distinction¶

This lifecycle applies specifically to architectural knowledge — not architectural data. The distinction between data and knowledge matters here because:

Data has a simpler lifecycle: collect → store → update → delete. It's factual and verifiable against running systems.
Knowledge has the richer lifecycle described here because it involves interpretation, rationale, and judgment that can't be automatically harvested or verified.

The lifecycle stages where knowledge differs most from data:

Create — data can be discovered automatically (APM, cloud APIs); knowledge requires human interpretation
Validate — data can be verified against reality; knowledge requires judgment about relevance and accuracy
Evolve — data is updated (the new value replaces the old); knowledge is superseded (the old reasoning is preserved alongside the new)
Retire — data can be deleted when the entity no longer exists; knowledge should be preserved as institutional memory

References¶

Architecture knowledge management¶

Kruchten, P., Lago, P., & van Vliet, H. (2006). "Building Up and Reasoning About Architectural Knowledge." QoSA 2006, LNCS 4214.
Jansen, A. & Bosch, J. (2005). "Software Architecture as a Set of Architectural Design Decisions." WICSA 2005.
Capilla, R., Jansen, A., Tang, A., Avgeriou, P., & Babar, M.A. (2016). "10 Years of Software Architecture Knowledge Management." JSS, 116, 191–205.
Farenhorst, R. & van Vliet, H. (2008). "Understanding How to Support Architects in Sharing Knowledge." SHARK 2008.
Lago, P. & Avgeriou, P. (2006). "First Workshop on Sharing and Reusing Architectural Knowledge." ACM SIGSOFT Software Engineering Notes, 31(5).

Knowledge lifecycle models¶

Nonaka, I. & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press.
Wiig, K.M. (1993). Knowledge Management Foundations. Schema Press.
Davenport, T.H. & Prusak, L. (1998). Working Knowledge. Harvard Business School Press.

Linked.Archi documentation¶

Architectural Data vs Architectural Knowledge — The foundational distinction
Enterprise Ontologies and the AI Context Problem — Why formalization is urgent
How Linked.Archi Bridges the Gap — The sharing and application stages in detail
Architecture & Approach — Technical architecture of the ecosystem

Architecture Knowledge Lifecycle¶

Introduction¶

The lifecycle¶

Stage 1 — Create¶

What happens¶

The knowledge produced¶

Where it breaks down¶

What helps¶

Stage 2 — Capture¶

What happens¶

Forms of capture¶

The capture gap¶

Where it breaks down¶

What helps¶

Stage 3 — Validate¶

What happens¶

Validation dimensions¶

Automated vs human validation¶

Where it breaks down¶

What helps¶

Stage 4 — Share¶

What happens¶

Audiences and formats¶

The sharing paradox¶

Where it breaks down¶

What helps¶

Stage 5 — Apply¶

What happens¶

Application patterns¶

Active vs passive application¶

Where it breaks down¶

What helps¶

Stage 6 — Evolve¶

What happens¶

Evolution triggers¶

Evolution vs decay¶

The versioning problem¶

Where it breaks down¶

What helps¶

Stage 7 — Retire¶

What happens¶

What gets retired¶

Retirement vs deletion¶

Where it breaks down¶

What helps¶

The full picture¶

Lifecycle health indicators¶

The decay curve¶

How Linked.Archi supports each stage¶

Relationship to the data/knowledge distinction¶

References¶

Architecture knowledge management¶

Knowledge lifecycle models¶

Linked.Archi documentation¶