SE-0108-CONTEXT-RELATIONSHIP-INVENTORY

Kontextgraph-Beziehungsinventur#

Zusammenfassung#

• Dokumente: 663
• graphfähige Wissenselemente: 347
• ausgeschlossene Struktur-Elemente: 81
• explizit typisierte Beziehungen: 110
• untypisierte Referenzkandidaten: 1667
• Wissenselemente ohne ⌘BeziehungEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext.: 110
• Wissenselemente nur mit untypisierten Kandidaten: 132
• Entwurf/ausdrücklich ausgenommen: 10
• Wissenselemente ohne stabile ID: 0

Fehlende Beziehungen#

• ◆Verantwortungsmodell für repositoryübergreifende ZusammenarbeitKanonische organisationsweite Zuordnung von Wissen, Realisierung, Werkzeugen und Runtime-Zustand zu den verantwortlichen Repositories. — relationship · EA-CROSS-REPOSITORY-RESPONSIBILITY-001
• ◉Dokumentation folgt dem ReifegradTechnisches Dokumentations-Artifact. — ⌘meaningBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen. · ◆KP-0006-DOKUMENTATION-FOLGT-DEM-REIFEGRADTechnisches Dokumentations-Artifact.
• ◆MVP-001 – Learning Nugget Seed ScopeTechnical documentation artifact. — meaning · MVP-001-LEARNING-SEED-SCOPE
• ◆Qualitatives Reifegradmodell des Wissens-FüllstandsVerbindliches qualitatives Reifegradmodell für einzelne semantische Einheiten. — meaning · EA-KNOWLEDGE-MATURITY-MODEL-001
• ◆EF-001 – Runtime is not a Source RepositoryRuntime ist materialisierter Betriebszustand und darf nicht wie ein Git-Repository behandelt werden. — context-time · EF-001
• ◆EF-002 – Storage Class determines permitted operationsZulässige Operationen werden durch die Storage-Klasse und nicht durch Pfadnamen bestimmt. — context-time · EF-002
• ◆EF-003 – Materialization without Verification is incompleteEine ausgeführte Änderung gilt erst nach automatisierter Verifikation und Evidence als erfolgreich. — context-time · EF-003
• ◆EF-004 – Administrative and application database identities must be separatedAdministrative MariaDB-Zugänge und laufende Anwendungszugänge besitzen unterschiedliche Zwecke und Rechte. — context-time · EF-004
• ◆EF-005 – User systemd services must not depend on system servicesUser-systemd-Units dürfen keine direkten Requires-Abhängigkeiten auf System-Units besitzen. — context-time · EF-005
• ◆EF-006 – Port ownership must be verified before restartVor einem Service-Restart muss nicht nur Portbelegung, sondern Eigentümerschaft geprüft werden. — context-time · EF-006
• ◆EF-007 – Import success is not Engineering successEin erfolgreicher Paketimport belegt noch keinen erfolgreichen Engineering-Lauf. — context-time · EF-007
• ◆EF-008 – Execution Evidence is an architecture artifactBuild-, Deployment- und Runtime-Nachweise sind referenzierbare Artefakte und nicht bloß vergängliche Logs. — context-time · EF-008
• ◆EF-009 – Roundtrip must execute and verify the deployed systemDer Engineering-Roundtrip endet erst nach Deployment, Restart und Verifikation des materialisierten Systems. — context-time · EF-009
• ◆EF-010 – Deployment is a coordinated runtime transactionBinary, Frontend, Runtime-Metadaten, Service-Lifecycle und Evidence müssen als ein konsistentes Deployment behandelt werden. — context-time · EF-010
• ◆EF-011 – Invisible state transitions block engineeringUnobservable interactions, policy decisions and state transitions prevent reliable verification and evolution. — context-time · EF-011
• ◆Referenz-Building-Block – Bootstrap- und InstallationsverwaltungTechnical documentation artifact. — ⌘artifactEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. · BOOTSTRAP-INSTALLATION-MANAGEMENT
• ◆Referenz-Building-BlockCanonical model for reusable solution-neutral building blocks. — artifact · REFERENCE-BUILDING-BLOCK
• ◆Artifact-ManifestmodellTechnical documentation artifact. — artifact · ARTIFACT-MANIFEST-MODEL
• ◆Bootstrap-VertragsmodellTechnical documentation artifact. — artifact · BOOTSTRAP-CONTRACT-MODEL
• ◆Engineering-Finding-ModellModell für nachvollziehbare Erkenntnisse aus realer Materialisierung und Betrieb. — context-time · RM-ENGINEERING-FINDING
• ◆Modell für menschenlesbare Code-VerträgeTechnical documentation artifact. — artifact · HUMAN-READABLE-CODE-CONTRACT-MODEL
• ◆Modell für menschenlesbare TestverträgeTechnical documentation artifact. — artifact · HUMAN-READABLE-TEST-CONTRACT-MODEL
• ◆QualitätsmodellTechnical documentation artifact. — meaning · QUALITY-MODEL
• ◆SpeicherbereichsmodellTechnical documentation artifact. — artifact · STORAGE-AREA-MODEL
• ◆PDCA und RückkopplungErklärt PDCA als Lern- und Rückkopplungsmodell der Wissensbasis. — context-time · EA-PDCA-RUECKKOPPLUNG-001
• ◆Engineering PhasesTechnical documentation artifact. — context-time · PHASES
• ◆ADR-002 – Implementierungsblöcke verwenden Artifact-ManifesteTechnical documentation artifact. — meaning · ADR-002-IMPLEMENTATION-ARTIFACT-MANIFESTS
• ◆ADR-003 – Menschenlesbare Code-VerträgeTechnical documentation artifact. — meaning · ADR-003-HUMAN-READABLE-CODE-CONTRACTS
• ◆ADR-004 – Menschenlesbare und stabilisierende TestsTechnical documentation artifact. — meaning · ADR-004-HUMAN-READABLE-AND-STABILIZING-TESTS
• ◆ADR-005 – Verification-Abdeckung statt TestdateizählungTechnical documentation artifact. — meaning · ADR-005-VERIFICATION-OVER-TEST-COUNTING
• ◆ADR-006 – Referenzorientiertes Engineering und schnelle MaterialisierungTechnical documentation artifact. — meaning · ADR-006-REFERENCE-FIRST-ENGINEERING
• ◆ADR-008 – Materialisierungserfolg erfordert VerifikationTechnical documentation artifact. — meaning · ADR-008-MATERIALIZATION-SUCCESS-REQUIRES-VERIFICATION
• ◆MVP-001 – Glossary Seed ScopeTechnical documentation artifact. — meaning · MVP-001-KNOWLEDGE-SEED-SCOPE
• ⌘EvidenceTechnical documentation artifact. — meaning · ART-DEF-0043
• ⌘ProvenienzTechnical documentation artifact. — meaning · ART-DEF-0044
• ⌘Kanonische QuelleTechnical documentation artifact. — meaning · ART-DEF-0045
• ⌘Completion BlockerTechnical documentation artifact. — meaning · ART-DEF-0046
• ⌘Freshness GateTechnical documentation artifact. — meaning · ART-DEF-0047
• ⌘RetentionTechnical documentation artifact. — meaning · ART-DEF-0048
• ⌘PromotionTechnical documentation artifact. — meaning · ART-DEF-0049
• ⌘FindingTechnical documentation artifact. — meaning · ART-DEF-0050
• ⌘UTF-8 MarkdownTechnical documentation artifact. — meaning · ART-DEF-0051
• ⌘Whitespace TokenTechnical documentation artifact. — meaning · ART-DEF-0052
• ⌘DiscoveryTechnical documentation artifact. — meaning · ART-DEF-0053
• ⌘IntakeTechnical documentation artifact. — meaning · ART-DEF-0054
• ⌘SHA-256Technical documentation artifact. — meaning · ART-DEF-0055
• ⌘Architecture Decision RecordTechnical documentation artifact. — meaning · ART-DEF-0056
• ◆Weitere KernbegriffeKeine Kurzfassung vorhanden. — meaning · EA-GLOSS-WEITERE-KERNBEGRIFFE-001
• ◆Vision-SpezialisierungLösungsbezogene Einordnung der Enterprise-Vision als selbstanwendende, rückverfolgbare Plattform. — meaning · SA-SE-0035-VISION-SPEZIALISIERUNG
• ◆Lösungsumfang und -grenzenVerbindliche Definition des konkreten Lösungsraums und seiner Architekturebenen. — meaning · SA-SOLUTION-SCOPE-AND-BOUNDARIES
• ◆MVP-001 als zeitlich begrenzte SubvisionOrdnet den bestehenden MVP-001-Vertrag als zeitlich begrenzte Subvision ein. — meaning · SA-MVP-001-SUBVISION-EINORDNUNG
• ◆EP-000 – Workbench-InteraktionskontextTechnical documentation artifact. — context-time · EP-000-WORKBENCH-INTERACTION-CONTEXT
• ◆MVP-001 – WissensinteraktionskontextSystemkontext für Provider, Workbench, Nutzer, Terminologie und Erklärungen. — context-time · MVP-001-KNOWLEDGE-INTERACTION-CONTEXT
• ◆Enterprise Theory SpecializationOrdnet die Solution Architecture als Spezialisierung der universellen Enterprise-Theorie ein. — meaning · SA-ENTERPRISE-SPECIALIZATION-001
• ◆MVP-001 – Capability-GeltungsbereichBegrenzt die für MVP-001 ausgewählten Enterprise Capabilities und kennzeichnet vollständige, partielle und nachgelagerte Solution-Ausprägungen. — meaning · MVP-001-CAPABILITY-SCOPE
• EP-002.2B – Contribution- und Kontext-Demonstrator — artifact · EP-002-2B-CONTRIBUTION-AND-CONTEXT-DEMONSTRATOR
• EP-002.2C – Workbench-Überwachbarkeit und Trace-Protokollierung — artifact · EP-002-2C-WORKBENCH-OBSERVABILITY-AND-TRACE-LOGGING
• ◆EP-002 – Plattform-KompositionsausschnittTechnical documentation artifact. — artifact · EP-002-PLATFORM-COMPOSITION-SLICE
• ◆MVP-001 – BeitragsrahmenvertragKonsolidierter Vertrag für deklarative Contributions, Registry, Policy, Personalisierung und Context Binding. — artifact · MVP-001-CONTRIBUTION-FRAMEWORK-CONTRACT
• ◆MVP-001 – Workbench-KompositionsvertragSolutionweiter Vertrag für Composition Root, registrierte UI-Beiträge und gemeinsamen Workbench-Kontext. — artifact · MVP-001-WORKBENCH-COMPOSITION-CONTRACT
• ◆EP-002R – Bootstrap- und InstallationsverwaltungsvertragTechnical documentation artifact. — artifact · EP-002R-BOOTSTRAP-INSTALLATION-MANAGEMENT-CONTRACT
• ◆MVP-001 – Adapter- und Provider-VertragSolutionweiter Vertrag für externe Capability Provider, Persistenz- und Engineering-Tool-Adapter. — artifact · MVP-001-ADAPTER-AND-PROVIDER-CONTRACT
• ◆MVP-001 – AnwendungsdienstgrenzeGrenzen zwischen UI, Application Services, Domain, Ports und Adaptern. — artifact · MVP-001-APPLICATION-SERVICE-BOUNDARY
• ◆MVP-001 – Command-, Query- und KontextdienstvertragVertrag für stabile Commands, Queries, Current User Context und korrelierte Ausführung. — artifact · MVP-001-COMMAND-QUERY-CONTEXT-SERVICE-CONTRACT
• ◆EP-002.1 – UI-ManifestmodellTechnical documentation artifact. — artifact · EP-002-1-UI-MANIFEST-MODEL
• ◆EP-002.2 – Contribution- und Workbench-KontextmodellDaten- und Zustandsmodell für Contributions, Zugriffspolitik und persönliche Workbench-Konfiguration. — context-time · EP-002-2-CONTRIBUTION-WORKBENCH-CONTEXT-MODEL
• ◆MVP-001 – Materialisierungs- und ProvenienzvertragVerbindlicher Vertrag für Materialisierungen, Herkunft, Roundtrip-Deltas und verlustarme Wiedereinspielung. — context-time · MVP-001-MATERIALIZATION-AND-PROVENANCE-CONTRACT
• ◆MVP-001 – ArbeitsbereichsvertragTechnical documentation artifact. — artifact · MVP-001-WORKSPACE-CONTRACT
• ◆MVP-001 – Runtime-ArchitekturvertragSolutionweiter Vertrag für Runtime Targets, Assemblies, Zustände und Betriebsgrenzen. — context-time · MVP-001-RUNTIME-ARCHITECTURE-CONTRACT
• ◆MVP-001 – Speicher- und ZustandsvertragKonsolidierter Vertrag für Source, Workspace, Runtime Storage, Persistenz und Evidence. — context-time · MVP-001-STORAGE-AND-STATE-CONTRACT
• ◆MVP-001 – Sicherungs- und Recovery-VertragSolutionweiter Vertrag für Backup, Restore, Rollback und Recovery Evidence. — context-time · MVP-001-BACKUP-RECOVERY-CONTRACT
• ◆MVP-001 – Build-VertragSolutionweite Spezialisierung des kanonischen Build-Vertrags für MVP-001. — context-time · MVP-001-BUILD-CONTRACT
• ◆MVP-001 – Deployment-TopologieLogische Deployment-Topologie des MVP ohne umgebungsspezifische Werte. — context-time · MVP-001-DEPLOYMENT-TOPOLOGY
• ◆MVP-001 – Deployment-TransaktionsvertragVertrag für koordiniertes, überprüfbares und wiederholbares Deployment. — context-time · MVP-001-DEPLOYMENT-TRANSACTION-CONTRACT
• EP-002 – Plattform-Shell — context-time · EP-002-PLATFORM-SHELL
• ◆BB-EP-013 – Bootstrap- und InstallationsverwaltungTechnical documentation artifact. — artifact · BB-EP-013-BOOTSTRAP-INSTALLATION-MANAGEMENT
• ◆MVP-001 – Regeln für menschenlesbare Code-VerträgeTechnical documentation artifact. — artifact · MVP-001-HUMAN-READABLE-CODE-CONTRACT-RULES
• ◆MVP-001 – Historische EntscheidungsdispositionSemantische Disposition des historischen ADR-Bestands gegenüber der aktuellen Solution Architecture. — meaning · MVP-001-HISTORICAL-DECISION-DISPOSITION
• ◆MVP-001 – Lösungsentscheidungs-GovernanceVerbindlicher Vertrag für Status, Scope, Provenance, Supersession und Traceability von Solution Architecture Decisions. — meaning · MVP-001-SOLUTION-DECISION-GOVERNANCE
• ◆SADR-014 – Workspace-Konsolidierung und AusführungsgrenzenVerbindliche Verantwortung für Workspace-Altbestand, Engineering Tools und Runtime im konsolidierten Roundtrip. — meaning · SADR-014-WORKSPACE-CONSOLIDATION-AND-EXECUTION-BOUNDARIES
• ◆SADR-015 – Universe-Registry-PersistenzentscheidungEntscheidet die Persistenzgrenze der historischen SQLite-Universe-Registry. — meaning · SADR-015
• ◆EP-000 – Workbench-WissensanforderungenTechnical documentation artifact. — meaning · EP-000-WORKBENCH-KNOWLEDGE-REQUIREMENTS
• ◆EP-002.1 – Workbench-GrundlagenanforderungenTechnical documentation artifact. — meaning · EP-002-1-WORKBENCH-FOUNDATION-REQUIREMENTS
• ◆EP-002.2 – AnforderungenAnforderungen an Contribution Loading, Workbench Context, Policy-Filterung und Personalisierung. — meaning · EP-002-2-CONTRIBUTION-FRAMEWORK-REQUIREMENTS
• ◆EP-002.2C – ÜberwachbarkeitsanforderungenTechnical documentation artifact. — meaning · EP-002-2C-OBSERVABILITY-REQUIREMENTS
• ◆EP-002R – Bootstrap-VerifikationsanforderungenTechnical documentation artifact. — meaning · EP-002R-BOOTSTRAP-VERIFICATION-REQUIREMENTS
• ◆MVP-001 – Building-Block-Governance-AnforderungenAnforderungen an Ownership, Mapping, Abhängigkeiten und Traceability der Solution Building Blocks. — meaning · MVP-001-BUILDING-BLOCK-GOVERNANCE-REQUIREMENTS
• ◆MVP-001 – Capability-RealisierungsanforderungenAnforderungen an Auswahl, Realisierung und Nachweis der MVP-001 Capabilities. — meaning · MVP-001-CAPABILITY-REALIZATION-REQUIREMENTS
• ◆MVP-001 – Komponenten-, Dienst- und Contribution-AnforderungenRequirements for component boundaries, application services, contributions and adapters. — meaning · MVP-001-COMPONENT-SERVICE-CONTRIBUTION-REQUIREMENTS
• ◆MVP-001 – Runtime- und Deployment-AnforderungenAnforderungen für Runtime, Assembly, Storage, Deployment, Promotion und Recovery. — meaning · MVP-001-RUNTIME-DEPLOYMENT-REQUIREMENTS
• ◆MVP-001 – Lösungsentscheidungs-Governance-AnforderungenPrüfbare Anforderungen an Konsistenz, Provenance und Traceability der Solution Architecture Decisions. — meaning · MVP-001-SOLUTION-DECISION-GOVERNANCE-REQUIREMENTS
• ◆MVP-001 – Einheitliche Artifact-Model-AnforderungenRückverfolgbare Anforderungen für Identität, Revision, Referenzauflösung, Materialisierung und Provenance. — meaning · MVP-001-UNIFIED-ARTIFACT-MODEL-REQUIREMENTS
• ◆EP-001 – Codebereichs-VerifikationsmatrixTechnical documentation artifact. — context-time · EP-001-CODE-AREA-VERIFICATION-MATRIX
• ◆EP-001 – JavaScript-TestvertragTechnical documentation artifact. — context-time · EP-001-JAVASCRIPT-TEST-CONTRACT
• ◆EP-001 – TestmatrixTechnical documentation artifact. — context-time · EP-001-TEST-MATRIX
• ◆EP-001 – VerifikationsmodellmaterialisierungTechnical documentation artifact. — context-time · EP-001-VERIFICATION-MODEL
• ◆EP-002.0B – Deployment-VerifikationsmatrixTechnical documentation artifact. — context-time · EP-002-0B-DEPLOYMENT-VERIFICATION-MATRIX
• ◆EP-002.1 – Workbench-Grundlagen-VerifikationsmatrixTechnical documentation artifact. — context-time · EP-002-1-WORKBENCH-FOUNDATION-VERIFICATION-MATRIX
• ◆EP-002.2 – VerifikationsmatrixVerifikationsmatrix für Contribution Loader, Policy, Personalisierung und Workbench Context. — context-time · EP-002-2-CONTRIBUTION-FRAMEWORK-VERIFICATION-MATRIX
• ◆EP-002.2B – Contribution- und Kontext-Demonstrator-VerifikationsmatrixTechnical documentation artifact. — context-time · EP-002-2B-CONTRIBUTION-AND-CONTEXT-DEMONSTRATOR-VERIFICATION-MATRIX
• ◆EP-002.2C – Überwachbarkeits-VerifikationsmatrixTechnical documentation artifact. — context-time · EP-002-2C-OBSERVABILITY-VERIFICATION-MATRIX
• ◆EP-002 – Plattform-KompositionsverifikationTechnical documentation artifact. — context-time · EP-002-PLATFORM-COMPOSITION-TESTS
• ◆EP-002R – Bootstrap-VerifikationsmatrixTechnical documentation artifact. — context-time · EP-002R-BOOTSTRAP-VERIFICATION-MATRIX
• ◆MVP-001 – Building-Block-Governance-VerifikationsmatrixVerifikation von Ownership, Reference Mapping, Abhängigkeitsgrenzen und Building-Block-Traceability. — context-time · MVP-001-BUILDING-BLOCK-GOVERNANCE-VERIFICATION-MATRIX
• ◆MVP-001 – Capability-Realisierungs-VerifikationsmatrixPrüft Scope, Realisierungsbeiträge und Nachweisketten der MVP-001 Capabilities. — context-time · MVP-001-CAPABILITY-REALIZATION-VERIFICATION-MATRIX
• ◆MVP-001 – Komponenten-, Dienst- und Contribution-VerifikationsmatrixVerification matrix for component, service, contribution and adapter contracts. — context-time · MVP-001-COMPONENT-SERVICE-CONTRIBUTION-VERIFICATION-MATRIX
• ◆MVP-001 – Vertragsabdeckungs-LückenreviewTechnical documentation artifact. — context-time · MVP-001-CONTRACT-COVERAGE-GAP-REVIEW
• ◆MVP-001 – Wissens-, Terminologie- und Erklärbarkeits-VerifikationsmatrixNachweismatrix für Knowledge, Terminology, Help, Search und Explainability. — context-time · MVP-001-KNOWLEDGE-TERMINOLOGY-EXPLAINABILITY-VERIFICATION-MATRIX
• ◆MVP-001 – Runtime- und Deployment-VerifikationsmatrixNachweismatrix für Runtime-, Assembly-, Deployment- und Recovery-Verträge. — context-time · MVP-001-RUNTIME-DEPLOYMENT-VERIFICATION-MATRIX
• ◆MVP-001 – Lösungsentscheidungs-Governance-VerifikationsmatrixVerification Matrix für den konsolidierten Solution-Decision-Bestand. — context-time · MVP-001-SOLUTION-DECISION-GOVERNANCE-VERIFICATION-MATRIX

Nur untypisierte Kandidaten#

• ◆Architekturentwicklung und semantische MigrationDefiniert historische Gesamtmodelle, führende Repositories und semantische Migration entlang der Architekturebenen. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Wissensgraph der UnternehmensarchitekturDokumentiert die semantischen Beziehungen zwischen den tragenden Enterprise-Artefakten. — 19 Kandidat(en), noch ohne Beziehungstyp
• ◆Semantisches Landing-Page-ModellZugängliches Navigationsmodell vom Ziel über Realisierung und Runtime-Evidence zurück zum Lernen. — 5 Kandidat(en), noch ohne Beziehungstyp
• ◆ArchitekturableitungsprinzipNiedrigere Ebenen spezialisieren und materialisieren höhere Ebenen, ohne sie neu zu definieren. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Katalog der Enterprise-GrundprinzipienKanonischer Katalog der aus der historischen Gesamtarchitektur übernommenen universellen Foundation-Prinzipien. — 11 Kandidat(en), noch ohne Beziehungstyp
• ◆Prinzip der Erklärbarkeit durch ReferenzVerlangt erklärbare Entscheidungen und Zustandsübergänge durch stabile Referenzen auf Wissen, Regeln und Evidenz. — 5 Kandidat(en), noch ohne Beziehungstyp
• ◆Überwachbarkeit by DesignVerlangt beobachtbare und erklärbare Actions, Decisions, State Transitions und Results. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Prinzip der semantischen BewahrungArchitekturwissen wird konsolidiert und nicht stillschweigend gelöscht oder umgedeutet. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Prinzip typisierter RelationshipsFachliche Zusammenhänge werden als typisierte semantische Relationships modelliert. — 5 Kandidat(en), noch ohne Beziehungstyp
• ◆Unternehmensabstraktion und LösungsspezialisierungDefiniert Enterprise als universelle Abstraktion und Solution als Spezialisierung eines Lösungsraums. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Kernontologie der UnternehmensarchitekturDefiniert Meaning, Artifact und Relationship als fundamentale semantische Familien sowie Identity als universelle Eigenschaft. — 6 Kandidat(en), noch ohne Beziehungstyp
• ◆SE-0039 — Meaning-KonsolidierungKonsolidiert historische Meaning-Kandidaten auf kanonische Quellen und dokumentiert Folgearbeit. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Gültigkeitsnetz für historische und aktuelle AussagenVerknüpft historische und aktuelle Aussagen durch typisierte Gültigkeits- und Evolutionsbeziehungen. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Zeitlicher KontextModelliert zeitliche Gültigkeit ohne historische Aussagen zu überschreiben. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Capability-RealisierungsmodellVerbindet Enterprise Capabilities über typisierte Beiträge mit wiederverwendbaren Reference Building Blocks. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Repositoryübergreifendes ReferenzmodellKanonische Syntax und Semantik repositoryqualifizierter Referenzen und Realisierungsketten. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆Evidence-Freshness-ModellTechnical documentation artifact. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆ErklärbarkeitsreferenzmodellDefiniert die universellen Bestandteile einer nachvollziehbaren maschinellen und menschlichen Erklärung. — 5 Kandidat(en), noch ohne Beziehungstyp
• ◆Wissensebenen-ProtokollierungsmodellHebt technische Ereignisse durch stabile Knowledge-, Decision-, Principle- und Evidence-Referenzen auf eine nachvollziehbare Wissensebene. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Feedback, PDCA und EvolutionVerbindet Vision, Plateaus, Evidence und kontinuierliche Evolution. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆Plateau-ModellDefiniert Plateaus als stabile, fähigkeitsorientierte Architekturzustände. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆ADR-011 – Überwachbarkeit by DesignBeschließt Observability und Explainability als verpflichtende Querschnittsfähigkeiten. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆ADR-012 – Universelle Enterprise-Ontologie und Execution-TheorieBeschließt universelle Enterprise-Abstraktion, drei semantische Familien und Execution als zeitliche Interpretation. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆ADR-013 – Capability-Verankerung und semantische GovernanceBeschließt fachliche Herkunft, typisierte Capability-Beziehungen und semantische Governance. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆ADR-014 – Erklärbarkeit durch stabile WissensreferenzenEntscheidet, dass Explainability auf stabilen Reason Codes, Knowledge References und Evidence References basiert. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆Kernbegriffe der UnternehmensarchitekturKurze verbindliche Abgrenzungen der zentralen Enterprise-Begriffe. — 6 Kandidat(en), noch ohne Beziehungstyp
• ◆ArtefaktEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Artifact GUIDDie artifactguid ist die stabile, globale und technische Identität eines Artefakts. Sie identifiziert das Artefakt dauerhaft und eindeutig, unabhängig von Dateiname, Ordner, Alias, Titel, Projektion oder Materialisierung. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Artifact IDDie Artifact ID ist die sprechende, menschenlesbare Identität eines Artefakts. In Markdown-Headern wird sie im Feld id geführt. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Single Artifact InstanceEin Artefakt existiert fachlich genau einmal im Universum der Engineering-Landschaft. Mehrfache Darstellungen, Verwendungen, Diagrammknoten, Runtime-Dateien, Reports oder Exportformate erzeugen keine weiteren Artefakte. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘AttributeAttribute sind Eigenschaften eines Artefakts. Sie werden nicht automatisch als eigene Artefakte modelliert. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘DimensionEine Dimension beschreibt eine Ausprägung eines Artefakts oder eines Attributwerts. Sprache ist keine Sonderbehandlung, sondern eine mögliche Dimension. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘RelationEine Relationship beschreibt eine fachliche oder technische Beziehung zwischen Artefakten. Sie erhält eine stabile eigene Relationship-Identität, wenn sie eigene Attribute, Status, Historie oder Governance trägt. Sie bleibt dabei ein eigenständiges UAM-Grundelement und wird nicht zu einem Artifact. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘ProjectionEine Projektion ist eine fachliche Sicht auf ein Artefakt oder eine Artefaktmenge in einem bestimmten Kontext. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘MaterializationEine Materialisierung ist die technisch erzeugte und persistierte Darstellung einer Projektion. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Single Point of TruthDie führende Quelle für fachliche Artefakte ist das Artefaktmodell beziehungsweise die Modellierungsdatenbank. Dateien, Reports, Runtime-Ressourcen und Exporte sind nur dann führend, wenn sie ausdrücklich als Quellartefakte des jeweiligen Arbeitsmodus definiert sind. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Runtime ResourceEine Runtime Resource ist eine materialisierte Laufzeitdarstellung freigegebener Artefakte oder Projektionen. Sie kann technisch als JSON, YAML, Resource-Bundle oder vergleichbare Datei vorliegen. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Documentation SourceEine Documentation Source ist die führende, manuell gepflegte Quelle einer Dokumentationsaussage oder Definition. Sie darf wiederverwendbare Definitionen referenzieren, soll sie aber nicht duplizieren. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Markdown Exchange FormatMarkdown ist in der Engineering-Landschaft ein Austausch-, Arbeits- und Reportformat. Es ist nicht die endgültige fachliche Quelle, sobald das Artefaktmodell als führende Modellierungsquelle verfügbar ist. — 3 Kandidat(en), noch ohne Beziehungstyp
• ⌘Documentation PublisherDer Documentation Publisher ist die Komponente, die Documentation Sources, Artefaktreferenzen, Navigation und Assets in menschenlesbare Reports materialisiert. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Reference ResolverDer Reference Resolver löst stabile Artefaktreferenzen wie ART-DEF-0001, konkrete ADR-IDs oder spätere GUID-basierte Referenzen gegen das Artefaktmodell beziehungsweise den aktuellen Markdown-Arbeitsbestand auf. — 5 Kandidat(en), noch ohne Beziehungstyp
• ⌘RendererEin Renderer erzeugt eine konkrete technische Ausgabeform aus einer vorbereiteten Dokumentationsprojektion. Beispiele sind HTML, PDF, Markdown, JSON oder ein Suchindex. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘ThemeEin Theme beschreibt die visuelle und strukturelle Gestaltung eines Reports, beispielsweise CSS, einfache JavaScript-Erweiterungen, Navigation, Logo, Schriftgrößen oder Farbdefinitionen. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Write ModelDas Write Model ist die fachlich führende Quelle veränderbarer Informationen. Hier entsteht und ändert sich fachliche Wahrheit über die dokumentierten Schreibpfade des jeweiligen Owners. Das Write Model ist ein fachlicher Architekturbegriff und kein konkretes Datenbankprodukt. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Operativ persistierter ZustandOperativ persistierter Zustand wird für Betrieb, Synchronisation, Verarbeitung, Nachvollziehbarkeit oder Wiederaufnahme dauerhaft geführt, ist aber keine fachliche Wahrheit des Write Models. Er kann eine eigene operative Identität und einen eigenen Lebenszyklus besitzen. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Ephemerer Runtime StateEphemerer Runtime State unterstützt eine laufende Interaktion oder Sitzung und darf ohne Verlust bestätigter fachlicher Wahrheit ablaufen oder verloren gehen. Presence, Cursor und kurzfristige Sitzungszustände sind typische Beispiele. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘CacheEin Cache ist ein technischer Beschleunigungsmechanismus für Inhalte aus einer bestehenden Zustandsklasse. Er ist keine eigenständige fachliche Zustandsklasse und darf keine konkurrierende fachliche Wahrheit erzeugen. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘GlossareintragEin Glossareintrag ist ein eindeutig identifizierbares Architecture Artifact, das die verbindliche Bedeutung eines Begriffs, seine Kurzdefinition, fachliche Heimat, Ownership und optional weitere Erklärungen, Synonyme, Abgrenzungen und Themenfelder beschreibt. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Fachliche Heimat eines GlossarbegriffsDie fachliche Heimat ist das genau eine primäre Themenfeld, das Verantwortung, Pflege und bevorzugten fachlichen Einstieg eines Glossareintrags bestimmt. Weitere Themenfelder dürfen zusätzliche Verwendungskontexte sichtbar machen, erzeugen aber keine zweite Heimat. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Semantische GlossarreferenzEine semantische Glossarreferenz verweist stabil auf die Identität und Bedeutung eines Glossareintrags. Sie legt nicht fest, ob eine Ausgabe daraus einen Link, eine Kurzdefinition, eine Fußnote, ein Popover oder eine andere Darstellung erzeugt. — 2 Kandidat(en), noch ohne Beziehungstyp
• ⌘Universe SnapshotVersionierte Zusammenstellung eines bekannten Universe-Zustands mit Artefaktidentitäten, Beziehungen, Issues, Eingangsständen und Validierungsergebnis. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘Universe Artifact Identity RegistryZentrale Autorität für universumsweit eindeutige Artefaktidentitäten, GUIDs, referenzierbare Aliase und führende Quellen. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘Task Context SnapshotMinimierter, versionierter Arbeitskontext aus betroffenen Artefakten, Repository-Katalogen und der erforderlichen Dependency Closure. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘Dependency ClosureAbgeschlossene Menge aller Artefakte und Repositorys, die für eine konkrete Prüfung oder Bearbeitung aufgrund ihrer Abhängigkeiten benötigt werden. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘Pending InputIssue-Zustand für ein derzeit nicht auflösbares Ziel, das durch ein noch nicht bereitgestelltes Repository oder Artefakt nachgeliefert werden kann. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘ReconciliationErneute, zustandsbasierte Bewertung des Universe Catalogs und seiner Issues nach geänderten oder nachgelieferten Eingängen. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘ProcessedDocumentMedienneutrale, validierte und bereits aufgelöste Dokumentprojektion, die einem Renderer zur Darstellung übergeben wird. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘Learning NuggetDidaktisches Wissensartefakt, das ein Architektur- oder Technikthema verständlich erklärt, ohne normative Architekturregeln zu ersetzen. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘Architecture Compliance ContractEin Architecture Compliance Contract verbindet eine Architekturregel mit konkreten Implementierungs- und Testnachweisen. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘ADREin ADR (Architecture Decision Record) dokumentiert eine Architekturentscheidung mit ihrem Kontext, ihrer Begründung und ihren Folgen. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆BedeutungBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆BeziehungEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext. — 3 Kandidat(en), noch ohne Beziehungstyp
• ⌘Building BlockEin Building Block ist ein abgegrenzter Baustein mit stabiler Verantwortung zur Realisierung von Capabilities. — 4 Kandidat(en), noch ohne Beziehungstyp
• ⌘CapabilityEine Capability beschreibt ein dauerhaft benötigtes fachliches Leistungsvermögen, nicht dessen technische Umsetzung. — 4 Kandidat(en), noch ohne Beziehungstyp
• ⌘CodeCode ist eine ausführbare oder interpretierbare technische Realisierung, die durch Tests und Runtime-Evidence überprüfbar bleibt. — 4 Kandidat(en), noch ohne Beziehungstyp
• ⌘FeatureEin Feature ist eine abgegrenzte, nutzbare und lieferbare Ausprägung einer Lösung. — 3 Kandidat(en), noch ohne Beziehungstyp
• ⌘GitGit ist das verwendete Versionsverwaltungssystem für nachvollziehbare Änderungsgeschichte. — 3 Kandidat(en), noch ohne Beziehungstyp
• ⌘Kontext und ZeitbezugKontext und Zeitbezug beschreiben, unter welchen Bedingungen und zu welchem Zeitpunkt eine Aussage oder Evidence gilt. — 3 Kandidat(en), noch ohne Beziehungstyp
• ⌘LedgerEin Ledger ist eine versionierte, menschenlesbare Ergänzung für ausgewählte Beziehungen. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘MetamodellEin Metamodell beschreibt die zulässigen Kategorien, Eigenschaften und Beziehungen, mit denen Wissen modelliert wird. — 4 Kandidat(en), noch ohne Beziehungstyp
• ⌘MVPEin MVP ist eine kleinste überprüfbare Materialisierung mit bewusst begrenztem Umfang. — 4 Kandidat(en), noch ohne Beziehungstyp
• ⌘PlateauEin Plateau ist ein zeitlich eingeordneter, freigegebener Reife- oder Materialisierungsstand. — 4 Kandidat(en), noch ohne Beziehungstyp
• ⌘ProvenienzProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘ReleaseEin Release ist ein bewusst freigegebener und nachvollziehbarer Stand von Artefakten und ihrer Realisierung. — 4 Kandidat(en), noch ohne Beziehungstyp
• ⌘ServiceEin Service ist eine abgegrenzte bereitgestellte technische oder fachliche Leistung mit klarer Verantwortung. — 4 Kandidat(en), noch ohne Beziehungstyp
• ⌘supersedessupersedes bedeutet: Ein neuer Stand löst einen früheren Stand explizit ab. — 1 Kandidat(en), noch ohne Beziehungstyp
• ⌘VisionEine Vision beschreibt eine langfristig gewünschte Wirkung und gibt der Weiterentwicklung eine gemeinsame Richtung. — 3 Kandidat(en), noch ohne Beziehungstyp
• ⌘Execution CapabilityBezeichnet die Capability zur kontrollierten technischen Ausführung und Nachweisführung, ohne die universelle Execution-Semantik zu ersetzen. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆GlossarvertragVerbindlicher Vertrag für Identität, Ownership, Lifecycle, Referenzierung und Sichten des Glossars. — 5 Kandidat(en), noch ohne Beziehungstyp
• ◆GlossareintragsvorlageKanonische Struktur eines Glossareintrags nach dem übernommenen Legacy-Vertrag. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆Eine gemeinsame Wissensbasis statt widersprüchlicher KopienVerständlicher Einstieg in die gemeinsame Wissensbasis der Lösung. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆Historische und aktuelle Gültigkeit in der SolutionSpezialisiert das Enterprise-Gültigkeitsnetz für Solution-Verträge, Entscheidungen und Revisionen. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆Zeitlicher Kontext der SolutionSpezialisiert zeitliche Gültigkeit für solutionweite Verträge. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Capability-Traceability-MatrixVerbindet die ausgewählten Enterprise Capabilities mit aktuellen Solution Building Blocks, Requirements und Verification-Artefakten. — 1 Kandidat(en), noch ohne Beziehungstyp
• EP-002.1 – Engineering-Workbench-Grundlage — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆EP-002.2 – manifestgesteuertes Contribution FrameworkArchitektur des rollenbasierten und personalisierbaren Contribution Frameworks der Engineering Workbench. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Komponenten- und DienstrealisierungFührende Komponentensicht und Realisierungskette zwischen Workbench, Application Backend, Services, Adaptern und Building Blocks. — 6 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – KomponentenkarteTechnical documentation artifact. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Wissens- und Erklärbarkeits-KomponentenvertragKomponentenvertrag für Workbench-Integration, Knowledge Panel und kontextbezogene Erklärungen. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆EP-001C – Go-Domain- und Repository-VertragTechnical documentation artifact. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆EP-001D – Anwendungs- und REST-VertragTechnical documentation artifact. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Wissens-, Terminologie- und ErklärbarkeitsdienstvertragServicevertrag für Provider, Auflösung, Suche, Hilfe und Erklärungen. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆EP-000 – WissensdomänenerweiterungBestehender EP-000-Ausschnitt des konsolidierten Knowledge-Modells. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆EP-001A – Domäneninvarianten und LebenszyklenTechnical documentation artifact. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆EP-001B – MariaDB-PersistenzmodellTechnical documentation artifact. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – DatengeltungsbereichTechnical documentation artifact. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Kanonisches DomänenmodellTechnical documentation artifact. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Kennungs- und ReferenzvertragVerbindlicher Vertrag für stabile Identifier, Referenzarten und deren Auflösung über Persistenz und Materialisierungen hinweg. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Wissens-, Terminologie- und ErklärbarkeitsmodellKanonisches Solution-Modell für Wissen, Terminologie, Hilfe, Erklärungen und Nachweise. — 5 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Einheitliche Artifact-Model-RealisierungSolutionweiter Realisierungsvertrag für Artefaktidentität, Revision, Lokalisierung, Beziehungen und kontrollierte Materialisierungen. — 10 Kandidat(en), noch ohne Beziehungstyp
• ◆EP-002.0B – Dienst-Deployment und RoundtripEP-002.0B-Spezialisierung des koordinierten Deployment- und Roundtrip-Vertrags. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆EP-002R – SpeicherbereichsmaterialisierungEP-002R-Spezialisierung der solutionweiten Storage-Class-Verträge. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Runtime-AssemblierungsvertragVertrag für versionierte, unveränderliche und verifizierbare Runtime Assemblies. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Runtime-ZielKompakte Zieldefinition für getrennte MVP-Runtime-Umgebungen. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆Plateau-SpezialisierungOrdnet solutionbezogene Engineering-Plateaus in das Enterprise-Plateau-Modell ein. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆Feedback- und PDCA-SpezialisierungOrdnet Feedback und PDCA als Lösungsspezialisierung der Enterprise-Evolution ein. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Artifact-ManifestzuordnungTechnical documentation artifact. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Building-Block-KarteTechnical documentation artifact. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Building-Block-Verantwortungs- und AbhängigkeitsmatrixFührende Zuordnung fachlicher Ownership, veröffentlichter Grenzen und zulässiger Abhängigkeiten der Solution Building Blocks. — 6 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Komponenten-, Dienst- und Building-Block-ZuordnungTraceability zwischen Komponenten, Serviceverträgen und aktuellen Solution Building Blocks. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Wissens-, Terminologie- und ErklärbarkeitszuordnungZuordnung des Knowledge-Clusters zu aktuellen Solution Building Blocks. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Modularitäts- und AbhängigkeitsregelnTechnical documentation artifact. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Building-Block-QualitätszieleTechnical documentation artifact. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Referenz-zu-Lösungs-Building-Block-ZuordnungMaps reusable Reference Building Blocks to solution-specific Building Blocks and their implementation/runtime materializations. — 6 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – LösungsentscheidungskatalogZentraler Katalog der aktuellen Solution Architecture Decisions und ihrer Traceability. — 13 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-002 – Artifact-ManifestmaterialisierungVerbindliche Solution-Entscheidung SADR-002 - Artifact Manifest Materialization. — 4 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-003 – Materialisierung menschenlesbarer Code-VerträgeVerbindliche Solution-Entscheidung SADR-003 - Human-Readable Code Contract Materialization. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-004 – QualitätsmodellmaterialisierungVerbindliche Solution-Entscheidung SADR-004 - Quality Model Materialization. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-007 – Speicherklassengesteuerter RoundtripVerbindliche Solution-Entscheidung SADR-007 - Storage-class-driven Roundtrip. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-008 – manifestgesteuerte Workbench-KompositionVerbindliche Solution-Entscheidung SADR-008 - Manifest-driven Workbench Composition. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-009 – Policy-gefilterte, nutzerkonfigurierbare ContributionsUI-Beiträge werden zuerst durch Policies begrenzt und anschließend innerhalb des erlaubten Rahmens personalisiert. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-010 – Strukturierte Überwachbarkeit für Workbench-ÜbergängeVerbindliche Solution-Entscheidung SADR-010 - Structured Observability for Workbench Transitions. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-011 – Dezentrale Wissensverantwortung und kontextbezogene VeröffentlichungEntscheidung zu dezentraler Inhaltshoheit und zentral komponierter Veröffentlichung. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-012 – Ports und Contributions als LösungsgrenzenComponents communicate through application ports; workbench extensions use validated contributions. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆SADR-013 – Unveränderliche Assemblierung und koordiniertes DeploymentEntscheidung für unveränderliche Assemblies und koordinierten Runtime-Austausch. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Wissens-, Terminologie- und ErklärbarkeitsanforderungenArchitekturrelevante Anforderungen für Knowledge, Terminology, Help, Search und Explainability. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Anforderungs-, Verifikations- und Traceability-VertragRepositoryweiter Vertrag für die nachvollziehbare Verbindung von Solution-Verträgen, Requirements, Realisierung, Verification und Evidence. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – AnforderungenTechnical documentation artifact. — 3 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – ArchitekturabnahmetestsTechnical documentation artifact. — 2 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Anforderungs-, Verifikations- und Traceability-MatrixRepositoryweiter Einstieg von Solution-Verträgen und Requirements zu Realisierung, Verification und Evidence-Grenzen. — 26 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – TeststrategieTechnical documentation artifact. — 1 Kandidat(en), noch ohne Beziehungstyp
• ◆MVP-001 – Einheitliche Artifact-Model-VerifikationsmatrixVerifikationsmatrix für stabile Identität, Revision, Beziehungen, Referenzen, Materialisierung und Roundtrip-Provenance. — 1 Kandidat(en), noch ohne Beziehungstyp

Entwurf oder ausdrücklich ausgenommen#

• ◆MVP Acceptance Criteria – erster produktiver VertikalschnittTechnical documentation artifact. — Status Draft
• ◆MVP Capability Selection – Multilingual Artifact PlatformTechnical documentation artifact. — Status Draft
• ◆Semantische Einordnung des MVP-SetupsTechnical documentation artifact. — Status Draft
• ◆MVP-SetupAusführliche Arbeitsgrundlage für den parallelen Neuaufbau von Enterprise Architecture, Engineering Platform, Netzwerksolution, Integrationen und Runtimes auf Basis des gemeinsamen Metamodells. — Status Draft
• ◆MVP Traceability – vom Ziel zur produktiven MaterialisierungTechnical documentation artifact. — Status Draft
• ◆Reference Artifact FoundationTechnical documentation artifact. — Status Draft
• ◆External Evidence Reference ModelReferenzmodell für nachvollziehbare externe Evidenz an einer fachlichen Aussage. — Status Draft
• ◆Grundlage des ReferenzmodellsTechnical documentation artifact. — Status Draft
• ◆Reference Pattern FoundationTechnical documentation artifact. — Status Draft
• ◆Grundlage des ReferenzprozessesTechnical documentation artifact. — Status Draft

Fehlende stabile Identität#